Rails 6.0.0 beta1 released

Adrien Poly on January 19, 2019

Hey Rails 6.0.0 beta1 has just been released 🎉 🚀. TL;DR Webpacker Webpack is now the official JS bundler, Sprockets remains the re... [Read Full]
markdown guide

The feature I'm more excited about is the multi DB support, you can finally easily setup a replica DB for reads and keep the writes in your main DB, with something like:

class AnimalsBase < ApplicationRecord
  connects_to database: { writing: :animals, reading: :animals_replica }

(taken from github.com/rails/rails/pull/34052)

Parallel testing support is interesting and useful, it's a great way to see if your testing suite has issues (some suites have codependencies that are unknown until you run them in parallel :D). Aside from the possible speed improvements.

I was reading just yesterday about the new autoloader which would hopefully eliminate those weird cases when you still need a require statement here and there.

Glad they also upgraded minimum Ruby to 2.5.

I'll go through the various changelogs when I have a bit more time and report back 🤣


Fully agree on the parallel testing. It forces you to make independent tests.


I agree these are the most exciting.

I can't say I was dying for Action Text but I think we'd probably make use of it. Nice to have a "standard" of sorts for internal tools.

Action MailBox also a nice to have just in case.


Does it keep the two DBs in sync automatically?

No, and you don't want that. You don't want a web framework to sync your DBs :D

What's the benefit of reading and writing from separate DBs? Performance?

Some RDBMSs have the concept of a read replica, which is a twin instance which is asynchronously kept up to date. With PostgreSQL basically you configure the database server telling it which is the main instance and which is the replica, the main instance ships its changes to the other database (which is read only to the user) and the DB applies such changes.

This has a few benefits:

  • a possible standby in case anything happens to the main DB
  • a backup of the data
  • possible performance improvements

Depending on the type of app, by writing to a DB and reading from the other allows you to "balance the load" among them. In the case of a read heavy app you can scale with multiple replicas to read from and the main DB to write to.

So if you hit the ceiling of a single DB instance or if you just want to balance the reads among more than one failover, you can consider using read replicas.

If the main DB goes down you can still direct traffic to the replicas and keep the app running.

A by-product of a read replica that's not used directly by the production app (a stand by) is that you can use it to do batch reporting and heavy calculations on your data without affecting the app writing and reading on the main DB.

code of conduct - report abuse