railsmechanic
Hi Alchemists,
we’re investigating whether the migration of our (simple) Rails API to Phoenix is a viable step for us.
As we can’t migrate the Rails database schema to ecto, I’m interested in how to use Phoenix just with raw SQL queries. Is it recommended to drop ecto and setup the database connection pooling etc. from scratch, or do you recommend to keep ecto because of all the great things like connection pooling etc.?
Long story short:
How to use Phoenix just with raw SQL queries? Are there any examples about that subject?
Many thanks
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
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.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
sashaafm
This Stackoverflow thread might be of interested and quite simple.
michalmuskala
I agree that the argument of changing the database is completely
nonsensical. I have yet to see a system that does not use any
database-specific queries.
I see the strength of ecto in different areas - changesets are extremely
powerful and convenient way to work with data in general, not necessarily
database-originating data. Custom type definitions and automatic casting
make it a breeze to build systems. There are also some additional features
around handling associations, properly parametrizing queries, etc. Making
queries composeable is also a powerful idea that simplifies code
tremendously.
While I could definitely live without queries and write raw SQL,
abstractions such as changesets, multi and types are definitely a huge
improvement.
andre1sk
If you opt for stored procedures as opposed to using raw queries you will actually gain a lot of flexibility compared to using ORM.
Last Post!
kylethebaker
The phoenix generators set you up with ecto by default (unless you pass --no-ecto), but otherwise phoenix doesn’t care about the database/ecto (although Phoenix.Html.Form can use changesets out of the box).
With ecto you can pass raw queries, though it ultimately comes down to the database adapter. You can pass raw sql strings or use the query builder. It’s entirely schema agnostic, though there are a few places that nudge you in a certain direction by providing sensible defaults. In these cases you are always able to override the defaults though.