dogweather
I’m making a simple Phoenix app to manage links to news. The articles relate to data in a Rails app. I’d like for the Phoenix tables to live alongside Rails tables in the same Postgres database and schema. The Phoenix app would get read-only access to the Rails tables, and vice-versa.
I’ve run into a couple of roadbumps:
- Both Rails and Phoenix use a table,
schema_migrations. But the tables’ structures as created by the frameworks are different. - Keeping everything in the same schema seems less problematic: both frameworks don’t work so well with multi-schema queries.
So, I wonder:
- Is it possible to customize the name of
schema_migrationsthat Phoenix maintains? - Or, if Phoenix needs its own Postrgres schema so that it can have its own
schema_migrations, then how does the multi-schema story look currently?
Is there another solution I don’t know about?
EDIT: I found that Rails allows the table name to be changed. This is probably all I need:
3.8.5 config.active_record.schema_migrations_table_name
Lets you set a string to be used as the name of the schema migrations table.
EDIT 2: I found how to configure this in Phoenix:
:migration_source - Version numbers of migrations will be saved in a table named schema_migrations by default. You can configure the name of the table via:
config :app, App.Repo, migration_source: "my_migrations"
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
cschmatzler
Not sure about Rails, but what’s the issue you’ve run in with Ecto?
LostKobrakai
Seems like there are already a few paths:
Though I’d also argue that you shouldn’t really have two migration systems run against the same db. Keep things either in rails (or in phoenix I guess) or move to an external to both migration system. Even more as the phoenix one should run with a read only user, which won’t be allowed to migrate anything on that db.
trisolaran
Ecto.Migrator.up accepts a
prefixoption with which you can specify a schema. Theschema_migrationstable will be created in that schema. From the CLI:mix ecto.migrate --prefix prefix_name.In the past 2 years I’ve been working on a Phoenix app that needed to live alongside a legacy application and share its database. In order to improve separation I decided to put my app’s “private” tables in a separate schema, with their own migrations.
I don’t recall what it was like with Rails, but with Ecto I had no issues or roadblocks with the multi-schema setup