Summarized using AI

SQLite on Rails: Supercharging the One-Person Framework

Stephen Margheim • September 27, 2024 • Toronto, Canada • Talk

In this video titled "SQLite on Rails: Supercharging the One-Person Framework," Stephen Margheim presents how the integration of Rails 8 with SQLite can streamline application development for solo developers. The session highlights a vision of Rails as a powerful yet simplified tool that can handle real-world production needs without the complexities typically associated with modern web applications.

Key points discussed include:
- Complexity of Modern Web Applications: Margheim compares the increasingly intricate architecture of web applications to rocket engineering, arguing that simplification is a path to progress.
- Rails 8 Enhancements: Rails 8 introduces production-ready defaults that allow developers to deploy applications without the usual plug-and-play complexity, particularly in its handling of data-bound components.
- SQLite and Rails Synergy: Margheim emphasizes SQLite's design as an embedded database, which simplifies operational requirements and reduces the surface area for potential issues, making it an ideal solution for applications needing minimal dependency.
- Real-world Viability: The talk explores the misconception surrounding SQLite's limitations in web applications but illustrates that with careful configuration and usage adjustments, SQLite can now function effectively in production alongside Rails 8.
- Successful Case Studies: Margheim shares examples such as 37 Signals' Campfire app and a Ruby video app that runs efficiently on SQLite, demonstrating the capacity to handle significant user loads on minimal infrastructure.
- Considerations for Use: Attendees are cautioned about SQLite's linear write capabilities and the importance of having a robust backup system in place. Margheim recommends using tools like Lightstream for backup solutions.
- Scaling Strategies: The video concludes with Margheim advocating for vertical scaling on powerful single machines instead of distributed systems, debunking the idea that only complex architectures can support modern web applications.

Main Takeaways:
- Combining Rails 8 with SQLite offers a powerful combination for solo developers, enabling the creation of production-grade applications without substantial infrastructure. This approach encourages developers to focus on simplicity, reducing complexity while maintaining the necessary features and performance.

SQLite on Rails: Supercharging the One-Person Framework
Stephen Margheim • September 27, 2024 • Toronto, Canada • Talk

The Rails 8 feature set perfectly complements SQLite's power in creating resilient, high-performance production apps, but still the question lingers: Can I really go all-in on #SQLite? Stephen Margheim illustrates how to leverage Rails and SQLite's full potential in your next venture, and when SQLite does and doesn't make sense for your application.

Find the slides here: https://fractaledmind.github.io/2024/10/16/sqlite-supercharges-rails/

#Rails #Rails8 #rubyonrails #sqlite

Thank you Shopify for sponsoring the editing and post-production of these videos. Check out insights from the Engineering team at: https://shopify.engineering/

Stay tuned: all 2024 Rails World videos will be subtitled in Japanese and Brazilian Portuguese soon thanks to our sponsor Happy Scribe, a transcription service built on Rails. https://www.happyscribe.com/

Rails World 2024

00:00:11.240 so the vision that David presented
00:00:14.599 yesterday for rails was exciting wasn't
00:00:18.119 it
00:00:19.720 yeah this vision of rails as a kind of
00:00:24.720 rocket engine that can launch your idea
00:00:28.960 from Hello World to IPO is bold and
00:00:34.120 beautiful but for those of us who have
00:00:37.239 already embraced this new no pass
00:00:40.480 mindset I expect that you like me have
00:00:43.960 probably felt like you needed to be a
00:00:46.160 kind of rocket scientist to then deploy
00:00:50.559 and run your application in
00:00:53.399 production and that makes sense because
00:00:57.160 much like rocket engines having
00:01:00.519 really grown more complicated and larger
00:01:03.519 with time when you look at what we might
00:01:06.200 call the standard web application
00:01:08.799 architecture that has also only grown
00:01:11.799 more
00:01:13.240 complex if you take a typical Heroku
00:01:16.680 application from 15 years ago sure it
00:01:20.560 was a distributed system but it was
00:01:24.320 understandable and
00:01:26.119 manageable well this is the typical hero
00:01:29.920 U application today where the number of
00:01:33.079 services and servers has
00:01:36.159 tripled and I'm sure that many of you
00:01:39.439 like me when I first saw this think well
00:01:42.240 this must simply be the cost of running
00:01:46.520 production grade
00:01:48.880 systems and it's easy enough to believe
00:01:52.280 that
00:01:53.399 complexity is the price we have to pay
00:01:56.960 for
00:01:58.280 progress but that's not always
00:02:01.640 true sometimes progress is
00:02:05.560 simplification sometimes progress is
00:02:08.200 removing moving Parts shrinking the
00:02:11.000 surface area of the system yet still
00:02:14.200 somehow expanding its functionality and
00:02:19.120 power so my name is Stephen you might
00:02:22.319 know me as fractal mind on Twitter and
00:02:25.840 today I want to show you my vision for
00:02:30.160 how rails 8 and sqlite together
00:02:33.840 supercharge rails as the oneperson
00:02:38.040 framework I want to present the
00:02:42.879 possibility of building
00:02:45.720 applications that have all of this power
00:02:49.760 but are this lean and this
00:02:53.159 simple because believe it or not this is
00:02:57.519 a viable application AR architecture
00:03:01.319 today and one that can serve tens of
00:03:04.959 thousands of
00:03:07.400 users you see to extend the metaphor
00:03:11.760 like liquid methane and liquid oxygen in
00:03:14.239 a rocket engine sqlite and rails when
00:03:18.239 mixed form a potent
00:03:21.920 combination on the one hand you have
00:03:24.040 rails with its two decades of battle
00:03:28.000 tested Solutions extra Ed from real
00:03:30.879 production
00:03:32.400 systems and on the other hand you have
00:03:35.000 sqlite with its three decades of
00:03:38.000 refinement of this vision of having a
00:03:43.360 operationally minimal embedded database
00:03:46.519 with just a single file on disk and an
00:03:48.920 executable that runs in your application
00:03:51.200 process and when you mix this conceptual
00:03:55.120 compression with this operational
00:03:57.599 compression you get powerful and
00:04:01.000 explosive results in what is a
00:04:04.360 remarkably lean and simple
00:04:07.200 application so what I want to do today
00:04:09.840 is show you
00:04:11.799 how and to start I want to retread some
00:04:17.239 of the ground that David went over
00:04:18.639 yesterday to show you how rails 8
00:04:22.360 specifically makes the rails new command
00:04:25.280 production
00:04:27.120 ready rails has always been a full
00:04:31.280 featured framework that came with all of
00:04:34.360 the components that you would need for a
00:04:36.880 full featured web application and many
00:04:40.240 of those components require some form of
00:04:43.919 persistent data we could call these the
00:04:47.360 datab bound components of rails and a
00:04:51.400 full-featured application is going to
00:04:53.919 need a data store to back each of
00:04:57.360 these and of course rails is a modular
00:05:00.400 framework so each component has various
00:05:03.919 adapters to work with different data
00:05:07.080 stores with version seven of rails when
00:05:10.280 you run rails new these are the
00:05:12.600 production defaults that you would
00:05:14.600 see and there's nothing broken or wrong
00:05:18.440 about these defaults but these are not
00:05:21.039 production ready Plug and Play
00:05:25.080 Solutions the async adapter for jobs
00:05:28.240 right is fast and simple locally but if
00:05:30.520 you run that in production you are going
00:05:32.600 to lose jobs on deploys or
00:05:36.479 restarts and the file system for caching
00:05:39.639 works great if you have a persistent
00:05:42.280 file system if you're on Heroku it's not
00:05:45.840 so great when your entire cache is
00:05:47.880 randomly
00:05:50.520 wiped well the red is adaptive for
00:05:52.840 Action cable that's certainly production
00:05:54.960 grade software but it isn't Plug and
00:05:57.319 Play you have to have a redus in
00:05:59.680 instance configured and running and
00:06:01.759 connected to your application in
00:06:03.479 production so sure production ready but
00:06:06.840 not Plug and
00:06:08.919 Play This is the major change with rails
00:06:12.680 8 with rails 8 you get an outof the-box
00:06:15.840 experience that is both production ready
00:06:18.919 and plug
00:06:21.280 andplay with version 8 when you run
00:06:23.680 rails new you're going to see these
00:06:26.599 notably
00:06:28.039 different defaults for the central datab
00:06:31.479 bound components of rails this Suite of
00:06:34.919 solid gems provide production ready
00:06:38.560 flexible and scalable
00:06:41.160 defaults for these
00:06:45.000 components and these database backed but
00:06:49.240 database agnostic of course you can use
00:06:51.199 them with postris you can use them with
00:06:52.680 my
00:06:53.400 SQL I hope by the end of this talk
00:06:56.319 you'll be interested to use them with
00:06:57.879 sqlite
00:07:00.319 offer a solid foundation for active job
00:07:05.680 active support cach and action
00:07:08.240 cable and I hope that you were here in
00:07:12.080 this room yesterday at this time to see
00:07:15.680 and here Rosa Tonk where she detailed
00:07:18.319 what makes solid Q truly production
00:07:21.400 grade software and last year at rails
00:07:24.840 World Donald introduced solid cache
00:07:27.639 detailing its thoughtful and again
00:07:30.560 production oriented
00:07:33.199 design and unfortunately Nick isn't able
00:07:36.919 to be here today but the work he has
00:07:39.520 done on solid cable allows you again to
00:07:43.800 have simple scalable agnostic default
00:07:48.319 experiences for your rails
00:07:51.400 applications but rails 8 being
00:07:53.680 production ready isn't simply about
00:07:55.759 these new defaults for rails components
00:07:57.960 because rails 8 also comes with an
00:08:01.479 improved out-of-the-box solution for
00:08:03.680 production deployments with
00:08:05.599 Kamal right Kamal offers everything you
00:08:09.199 need to deploy and manage your web
00:08:12.240 application in production with Docker
00:08:15.759 and yesterday Donald introduced the new
00:08:18.479 version of Kamal Kamal 2.0 and Kevin
00:08:21.720 introduced the new Kamal proxy so I hope
00:08:24.800 you were here to see what the future of
00:08:27.800 deploying and running rail applications
00:08:30.560 looks like but if you weren't you can
00:08:33.399 catch it on
00:08:35.000 YouTube all in all rails 8 provides the
00:08:38.279 tools that you need to go from Hello
00:08:41.599 World to hello web just with rails
00:08:46.040 new and these are the features and
00:08:49.120 details that make rails the oneperson
00:08:52.839 framework as David outlined in his
00:08:55.279 keynote last year and reiterated with
00:08:58.680 his hi coup this year rails aims to be a
00:09:02.399 bridge over
00:09:04.079 complexity that allows the smallest
00:09:07.120 possible team right you and your laptop
00:09:10.839 to build full Rich valuable web
00:09:15.839 applications and sqlite aligns perfectly
00:09:20.320 with that Vision I like to say that
00:09:23.240 sealite supercharges
00:09:26.240 rails because sqlite is what enables you
00:09:30.680 to go from the moderate complexity of a
00:09:34.120 minimally distributed system to the
00:09:37.240 radical Simplicity of an application and
00:09:41.480 all of its operational dependencies
00:09:43.720 living on a single
00:09:45.839 machine and this is possible because of
00:09:50.120 sqlite's unique
00:09:52.880 architecture most client server
00:09:55.720 databases run in a separate process
00:09:59.519 often on a separate
00:10:02.040 machine but sqlite runs embedded within
00:10:06.720 your Ruby process and the thread that
00:10:08.800 spawns it so it's not a database in the
00:10:13.320 way that you might be used to right it's
00:10:16.000 just a file on disk and an executable
00:10:20.320 that runs within your application
00:10:23.519 process nonetheless it is a full
00:10:27.480 featured SQL engine with CTE window
00:10:31.240 functions aggregations and anything else
00:10:35.000 from the SQL standard and many things
00:10:37.480 that aren't in the SQL
00:10:39.839 standard and this is stable
00:10:43.639 software sqlite's current major version
00:10:46.600 version 3 was released two decades ago
00:10:49.279 in
00:10:50.800 2004 and today there are an estimated 1
00:10:54.839 trillion sqlite databases in active use
00:10:58.880 around the globe making sqlite the
00:11:01.360 single most used database in the
00:11:06.000 world and I would forgive you if you
00:11:10.720 presume that an embedded
00:11:13.920 database could only possibly manage a
00:11:17.839 small fraction of the data that a proper
00:11:22.079 client server database can
00:11:24.760 handle but of course you would be wrong
00:11:28.560 sqlite can handle databases up to 280
00:11:33.639 terabytes or to put it otherwise you
00:11:36.800 won't hit its computational limits right
00:11:40.000 I
00:11:41.200 promise and when you pair the power and
00:11:45.000 simplicity of sqlite with Modern
00:11:47.959 Hardware hopefully you're starting to
00:11:49.920 get a sense of how sqlite enhances the
00:11:53.399 vision of rails as the oneperson
00:11:55.639 framework enabling us to radically
00:11:58.800 simplify ify our application's
00:12:01.000 operational
00:12:03.519 needs but as I say this I know that we
00:12:08.000 have had years and years of people
00:12:10.880 consistently saying that sqlite simply
00:12:14.839 doesn't work for web
00:12:18.399 applications indeed for the last few
00:12:20.519 years if you ran sqlite in production
00:12:22.959 rails would tell you it doesn't work go
00:12:27.040 elsewhere and the last time you read the
00:12:29.560 rails guides it explicitly warned you
00:12:32.519 against using sqlite in
00:12:35.240 production but this is an outdated point
00:12:38.680 of view and the reality is that today
00:12:42.440 this sentiment is a
00:12:45.240 myth and more and more people are
00:12:47.880 starting to realize
00:12:50.079 it the fact of the matter is that this
00:12:54.519 myth though persists for a reason it
00:12:58.320 does have Foundation
00:12:59.880 because sqlite in the context of web
00:13:02.560 applications is easily misunderstood and
00:13:07.079 misused you see unlike much of modern
00:13:10.399 software sqlite cares more about
00:13:14.040 backwards compatibility than it does
00:13:16.800 about enabling newer and more powerful
00:13:19.360 features by
00:13:20.959 default the maintainers care deeply that
00:13:24.760 a sqlite database created two decades
00:13:27.600 ago will be able to be opened by sqlite
00:13:31.480 two decades from now and that is one of
00:13:34.440 the key reasons why sqlite is the
00:13:36.680 archival format for Digital Data by the
00:13:39.720 US Library of
00:13:41.880 Congress but this means that for all
00:13:44.839 intents and purposes if you run sqlite
00:13:47.800 out of the box today it's as if you're
00:13:51.079 running sqlite as it was created 20
00:13:54.360 years ago and it's true 20 years ago
00:13:57.759 sqlite was not not well suited for web
00:14:02.120 applications so sqlite needs
00:14:06.440 fine-tuning and luckily over the last
00:14:09.160 two decades there have been many
00:14:12.160 features added to sqlite that do make it
00:14:15.600 suitable for web
00:14:17.680 applications all that is needed is to
00:14:20.279 fine-tune its configuration and its
00:14:23.240 usage and that is precisely what myself
00:14:27.800 and the rails core team
00:14:29.639 and the rest of the Rails Community have
00:14:32.639 been doing for the last year and a
00:14:36.880 half and that work is finally
00:14:39.720 culminating in rails
00:14:42.680 8 many of these pool requests have been
00:14:45.759 released in various previous versions of
00:14:48.000 rails but there are two in particular
00:14:50.320 coming out with rails 8 that weren't
00:14:53.639 special
00:14:54.800 consideration because these changes make
00:14:57.839 rails 8 the first version of rails and
00:15:00.519 as far as I know the first version of
00:15:02.880 any web application
00:15:05.480 framework that provides a fully
00:15:08.440 production ready sqlite experience out
00:15:12.480 of the
00:15:14.680 box so the two issues that hindered the
00:15:18.199 default experience of sqlite on Rails up
00:15:20.839 till
00:15:21.680 now were firstly that as your
00:15:25.519 application was put under more and more
00:15:27.920 concurrent load a growing percentage of
00:15:31.040 your requests would simply error out you
00:15:35.040 can see here that even at just four
00:15:37.120 concurrent requests nearly half of the
00:15:39.360 responses are errors and of course this
00:15:42.600 is utterly unacceptable for
00:15:45.240 production the second problem related to
00:15:48.800 your application's tail latency under
00:15:51.519 again increasing concurrent load you
00:15:53.800 would see your P99 or even eventually
00:15:56.120 your P95 latency Skyrocket
00:15:59.759 and when some requests are taking five
00:16:01.959 plus seconds to
00:16:03.360 respond it's fair to say this is not
00:16:06.279 production ready
00:16:09.040 software both issues arise from the
00:16:12.160 nuances of using an embedded database in
00:16:16.440 a multi-threaded web
00:16:18.319 application since rail spins up multiple
00:16:21.360 threads to process incoming requests and
00:16:24.199 each thread has its own embedded
00:16:26.160 connection to the sqlite database in
00:16:28.560 fact it its own connection pool rails
00:16:31.199 must ensure firstly that those
00:16:33.720 connections don't
00:16:35.519 conflict but also that they don't
00:16:39.800 block and to ensure that these embedded
00:16:43.240 connections don't conflict with each
00:16:45.040 other we have to make changes to the
00:16:47.040 ways in which rails manages transactions
00:16:49.759 for sqlite
00:16:53.199 databases and to ensure that these
00:16:56.199 connections don't block each other and
00:16:58.199 create these problems we actually had to
00:17:01.040 work on a pair of pull requests one in
00:17:03.000 the lower level sqlite gem which is the
00:17:06.959 engine that drives sqlite through Ruby
00:17:10.039 and then the other in rails to make use
00:17:11.880 of this feature now unfortunately I
00:17:14.600 don't have the time today to dig into
00:17:16.720 the technical details but if you are
00:17:18.880 interested in learning more I have an
00:17:20.959 in-depth post on my blog that walks
00:17:23.319 through every detail of these changes
00:17:25.400 the nature of the problems the reasoning
00:17:27.439 behind the solutions and the details of
00:17:29.360 the
00:17:30.559 implementation but details aside the
00:17:33.080 results speak for themselves not only do
00:17:36.440 we no longer see errored responses but
00:17:39.400 our P99 latency is literally improved
00:17:42.400 1,000 times under heavier concurrent
00:17:45.400 load and in fact we can see that these
00:17:48.240 improvements Hold Steady even for the
00:17:50.880 very slowest requests in our
00:17:54.880 Benchmark these configuration and usage
00:17:57.760 changes require nothing of you in your
00:18:00.720 application code and they unlock the
00:18:03.520 full power and speed of sqlite which now
00:18:07.039 make sqlite a viable production
00:18:11.400 option you can now back four out of the
00:18:14.480 five data bound components of rails with
00:18:17.280 sqlite without
00:18:19.840 compromise and this is precisely what
00:18:23.159 unlocks this architecture as a viable
00:18:26.360 option a full featured rails application
00:18:30.799 with no compromises on features or
00:18:33.679 performance all running on a single
00:18:37.039 machine now again I recognize that this
00:18:40.679 is a somewhat radical suggestion and I
00:18:44.120 expect that many of you are thinking
00:18:45.640 right now that this architecture
00:18:48.039 couldn't possibly serve production level
00:18:53.039 workloads so let's quickly investigate
00:18:56.960 and I want to start with using the
00:18:58.960 campfire app released earlier this year
00:19:01.120 by 37 signals both because it's a full
00:19:05.200 production grade full featured
00:19:07.360 application but also because the team at
00:19:09.720 37 signals that built it provided a load
00:19:12.080 testing tool in the source code itself
00:19:16.200 now campfire does not go all in on
00:19:19.320 sqlite it was built before all of these
00:19:22.240 Solutions were in the framework but
00:19:24.240 rails is a modular framework so I just
00:19:27.039 swapped the adapters out and as a side
00:19:29.880 note this took me literally 45
00:19:33.919 minutes and once I had the solid gems in
00:19:37.559 place rails 8 as the version of rails I
00:19:40.400 ran their load tests and again the
00:19:44.480 results speak for themselves whether
00:19:46.919 you're looking at the number of
00:19:48.360 connections spawned or the number of
00:19:51.240 messages received the campfire on sqlite
00:19:54.200 Fork performs just as well as the
00:19:56.840 standard campfire build and the team at
00:19:59.679 37 signals ran load tests on big beefy
00:20:03.080 servers and they were able to handle
00:20:04.919 50,000 concurrent users no
00:20:07.679 problems but we don't have to only look
00:20:10.400 at this speculative load test there are
00:20:12.440 applications today that are running on
00:20:14.880 this architecture this is the Ruby video
00:20:17.960 app built by my friend Adrien Polly it
00:20:20.440 runs on a single $4 a month hetner box
00:20:23.760 with sqlite backing all of its IO needs
00:20:26.440 and it has served millions of requests
00:20:28.960 with an average response time of less
00:20:30.720 than 100 milliseconds and it has four
00:20:33.360 nines of up
00:20:35.240 time I have also been running
00:20:37.600 applications in production with sqlite
00:20:39.919 unfortunately they're all proprietary
00:20:42.280 and associated with ndas with big
00:20:44.200 corporations but I can tell you that
00:20:47.480 these applications have been running
00:20:49.679 smoothly for three years they have
00:20:53.039 driven millions of dollars in revenue
00:20:55.480 and they have never had a complaint from
00:20:57.640 customers or or from the
00:21:00.679 business of course recently Tech Twitter
00:21:03.440 has been chatting incessantly it seems
00:21:05.320 about Peter levels' setup where he runs
00:21:08.440 multiple successful applications all
00:21:11.159 backed by sqlite on a single beefy
00:21:14.080 VPS and as a reminder single server
00:21:16.679 deployments have been serving rails
00:21:18.240 applications quite well since day
00:21:21.360 one so yes it really is possible to run
00:21:25.360 a full-featured rails application in
00:21:27.880 production with no compromises on a
00:21:30.840 single
00:21:32.159 machine so I hope that you trust me or
00:21:35.600 you're at least beginning to trust me
00:21:37.480 when I say that this idea is a
00:21:40.000 myth and next year I'm hoping to hear
00:21:43.120 stories from some of you about
00:21:45.840 applications that you have created and
00:21:47.760 are now running for months successfully
00:21:50.679 so we can add even more evidence to show
00:21:54.039 that this is simply no longer the
00:21:56.559 case but I don't want to stand here and
00:22:00.360 make it seem like this is some sort of
00:22:02.360 Silver Bullet because it isn't there are
00:22:05.320 use cases where this architecture shines
00:22:07.840 and those where it
00:22:09.360 doesn't and there are areas where you do
00:22:12.120 need to be
00:22:14.600 considerate firstly when running SQL
00:22:17.679 item production you need to have a solid
00:22:20.720 backup mechanism set up and I know this
00:22:24.000 because I have deleted my production
00:22:25.919 database and it was not a fun on
00:22:29.640 weekend I think that the best tool for
00:22:31.720 the job is light stream this is a
00:22:33.520 utility that streams each change to your
00:22:36.919 database to some S3 compatible bucket
00:22:39.880 storage system that you have
00:22:42.279 configured you could even stream it to
00:22:44.240 an FTS server that you've set up if
00:22:46.159 that's your cup of tea so you get point
00:22:48.480 in time backups with incredibly cheap
00:22:51.480 storage costs and since it's only a
00:22:54.000 single go executable I've wrapped it up
00:22:55.880 in a pre-compiled binary gem so
00:22:57.919 installation is a breeze and the gem
00:23:00.760 provides a puma plugin so you could
00:23:02.360 manage the replication process with a
00:23:05.159 simple single line in your config so it
00:23:08.720 truly is a plug- Inplay solution and it
00:23:11.480 even ships with a verification job that
00:23:13.679 you can schedule to run continuously
00:23:16.559 every day at midnight if you want to
00:23:19.200 verify that your backup system is
00:23:22.960 working aside from data resilience
00:23:25.480 probably the most common worry I hear
00:23:27.360 centers on the fact that sqlite only
00:23:29.240 currently supports linear
00:23:31.279 rights and the worry is that only having
00:23:33.760 one operation at a time will prevent
00:23:36.640 your application from scaling whatever
00:23:39.840 that might mean but this worry is
00:23:42.360 overblown firstly most applications are
00:23:45.440 read heavy not write heavy so likely
00:23:47.880 only around 20% of your traffic is wrs
00:23:51.159 plus we easily forget what a difference
00:23:54.080 it makes when you're using an embedded
00:23:56.919 database even if if you are running
00:23:59.200 postgress on the same machine as your
00:24:01.240 application the simple interprocess
00:24:03.840 communication overhead means that you
00:24:05.440 could execute 10 sqlite queries linearly
00:24:08.760 in the same amount of time that it takes
00:24:10.320 to run one postgress queries and as
00:24:13.640 applications are generally moving away
00:24:15.279 from self-hosting and managing the own
00:24:16.840 database server and Cloud databases are
00:24:19.200 more popular than ever when using a
00:24:21.720 cloud database even if it is in a
00:24:24.480 neighboring region you could run 600
00:24:27.399 sqlite queries in the time it takes you
00:24:29.840 to execute that one postgress query so
00:24:32.880 when you go from a client server
00:24:34.640 database architecture with network
00:24:36.159 latency to an embedded database your
00:24:39.080 queries go from being measured in
00:24:40.600 milliseconds to
00:24:42.640 microseconds and that mostly erases the
00:24:46.720 problems that you might think come from
00:24:48.799 only allowing linear
00:24:50.960 rights but if you are ingesting lots of
00:24:54.000 data and by a lot I mean something on
00:24:56.399 the order of magnitude of like 50,000
00:24:58.640 rights per
00:24:59.760 second probably sqlite won't work for
00:25:02.520 you use postgress use my SQL that's fine
00:25:05.520 use the tool that's best for your
00:25:07.559 problem but if you're not at that level
00:25:10.360 sqlite is going to work fine and have no
00:25:12.840 meaningful impact on your application
00:25:15.960 performance but linear rights do mean
00:25:19.080 that you have to be thoughtful about
00:25:20.760 migrations if you have a long running
00:25:23.520 and right intensive migration like
00:25:26.520 adding a new index to a table with a
00:25:28.520 million or 10 million rows that
00:25:30.840 migration will impact your application's
00:25:33.640 performance and there are currently no
00:25:35.840 popular or battle tested solutions to
00:25:37.679 get around this limitation so be aware
00:25:40.159 that such migrations are going to be
00:25:41.760 handled much more simply with just
00:25:45.120 scheduled
00:25:47.039 downtime in general getting familiar and
00:25:50.640 comfortable with scheduled downtime is
00:25:53.000 going to be useful if you want to
00:25:54.600 embrace sqlite because sqlite works best
00:25:57.600 on a single machine and this means that
00:26:00.240 as you need to scale you should simply
00:26:02.880 expand the size of that machine over
00:26:05.200 time now there's a fair chance that many
00:26:07.919 of you imagine that the size of machine
00:26:11.480 that you can rent is relatively limited
00:26:15.120 but you can rent a really big box like a
00:26:19.799 really really big box any person who
00:26:23.520 signs up on hetner can get a 48 core 19
00:26:28.320 2 gig of RAM one terabyte of nvme SSD
00:26:31.679 space for $350 a month that thing is a
00:26:36.279 beast and it's available to all of us so
00:26:39.720 don't put an artificial ceiling on how
00:26:41.760 far vertical scaling can take an
00:26:44.279 application and I know that we've all
00:26:46.480 been told for the last decade that the
00:26:48.240 only correct way to build web apps is
00:26:50.880 with redundancy and high availability
00:26:53.960 and automatic failovers and zero to
00:26:56.279 Infinity Auto scaling and everything
00:26:58.039 else else but the fact is that these are
00:27:00.440 solutions to problems that a minority of
00:27:02.919 web applications do have or will ever
00:27:06.039 have and they come with real tradeoffs
00:27:09.200 around operational complexity we need to
00:27:12.320 remember that the larger the surface
00:27:14.240 area of our systems the more
00:27:16.520 opportunities for
00:27:18.720 failures so ask yourself do you truly
00:27:22.360 need all of that especially on day one
00:27:26.360 or should you start with a stack that is
00:27:28.640 simple enough to keep in your head yet
00:27:30.960 powerful enough to serve all of your
00:27:32.840 customers
00:27:34.080 needs so like any tool sqlite comes with
00:27:37.880 tradeoffs and you need to learn that
00:27:40.799 tool its quirks and idiosyncrasies if
00:27:42.799 you want to make maximal use of it but
00:27:45.480 when you choose High leverage tools
00:27:48.320 tools that are well built and well known
00:27:51.360 tools that might be considered boring
00:27:54.080 you unlock the power of simplicity
00:27:58.559 and you truly can build an application
00:28:00.919 that has the power to take your next
00:28:03.640 idea to IPO but you don't need to be a
00:28:07.880 rocket scientist to run it rails 8 and
00:28:11.399 sqlite strip away all of the incidental
00:28:14.799 complexity leaving you with the leanest
00:28:18.240 simplest but most powerful application
00:28:20.919 stack that I could imagine and few
00:28:24.799 things are as powerful as the tools that
00:28:27.960 have have earned their Simplicity
00:28:29.960 through years of evolution and
00:28:34.320 consideration these are the kinds of
00:28:36.679 engines that Empower individuals to
00:28:39.760 build production grade full-featured
00:28:43.240 valuable applications faster simpler and
00:28:46.880 cheaper than ever before and I really
00:28:49.960 truly believe that we are on the cusp of
00:28:54.200 a new wave of opportunity for rails
00:28:56.760 developers to to make their stand in the
00:29:00.799 greater Marketplace of the internet and
00:29:05.159 pursue their dream of building something
00:29:08.600 that can sustain their livelihoods while
00:29:12.000 pursuing their
00:29:15.120 interests sqlite and rails are a unique
00:29:18.760 pair a powerful pair and I hope that
00:29:21.720 after this exploration you better
00:29:23.840 understand and appreciate how well
00:29:25.880 sqlite pairs with rails as an engine for
00:29:28.480 creativity and building and I hope you
00:29:31.399 feel confident that you could or even
00:29:33.399 that you might want to build and run
00:29:36.240 your next rails application going all in
00:29:38.919 on
00:29:39.919 sqlite so thank you
Explore all talks recorded at Rails World 2024
+33