Ruby on Rails continues to be a lively and thriving framework. Unfortunately, when it comes to the database adapters, a vast majority of the attention and effort has been focused on the MySQL and PosgreSQL adapters. SQLite supports a large percentage of the database features that Rails has added support for in the recent past. So, today I am starting to do my part to make the developer experience of using Rails with SQLite as seamless and powerful as possible. Maybe you’ll join me?
Today I opened my first two pull requests to begin improving Rails’ SQLite3Adapter:
And this blog post is my personal declaration of intent—I am going to do my part in bringing as many of the newer ActiveRecord features to the SQLite adapter. From composite foreign keys to virtual columns, with auto-populated columns thrown in, SQLite will no longer lag behind PostgreSQL and MySQL.
But, this is no simple task, and I’m certain there are many more features beyond the ones I have bumped into. So, this post is also a call to action. If you are a SQLite and Rails enthusiast, join me! Let’s start leveling up the SQLite3Adapter together. Because one step at a time, we can help surge the tide of SQLite in production usage for Rails applications.
That’s it for today. But be on the lookout for a post on how supporting Rails’ RETURNING feature opens up the possibility for UUIDs or ULIDs as primary keys.
All posts in this series #
- Part 1 — branch-specific databases
- Part 2 — fine-tuning SQLite configuration
- Part 3 — loading extensions
- Part 4 — setting up
Litestream - Part 5 — optimizing compilation
- Part 6 — array columns
- Part 7 — local snapshots
- Part 8 — Rails improvements
- Part 9 — performance metrics
- Part 10 — custom primary keys
- Part 11 — more Rails improvements
- Part 12 — table schema and metadata
- Part 13 — prefixed ULID keys
- Part 14 — installing extensions