Stephen Margheim - How (and why) to run SQLite in production

Поделиться
HTML-код
  • Опубликовано: 10 фев 2025
  • Stephen is an American expat living in Berlin with his wife and two dogs. He is a contributor to Ruby on Rails, sqlite3-ruby gem, and the maintainer of a handful of gems aimed at making Ruby and Rails the absolute best platforms in the world to run SQLite projects. For his day job, he is an engineering manager at Test IO.
    Join him on a journey to explore the use-cases and benefits of running SQLite in a production environment.

Комментарии • 7

  • @denissorn
    @denissorn 2 месяца назад +4

    500 requests per second is ridiculously low for SQLite. I'm assuming this is b/c of RoR? Would it work faster simply b/c of a different DBMS?

  • @MattCCrampton
    @MattCCrampton 4 месяца назад +3

    I guess I’m missing something fundamental after listening to this talk, I have two servers that talk to the same database. As far as I can tell using SQLite in prod does not scale past a single server. Is there something here I didn’t understand?

    • @Dominik-K
      @Dominik-K 4 месяца назад +2

      That is true in itself, though offerings like Turso /LibSQL make it possible to have changes be synchronized between a central server and your web servers.
      Before Turso, I've deployed some applications that just redirected write traffic to a master server and used tools, like Litestream, to update the read replicas automatically.
      Using Sqlite with multiple databases and database files, one person tenant, made it possible to still distribute writes, since each server was the master of a few of those tenants.
      With tools like Turso the effort to implement such solutions goes down dramatically though

    • @TheRealCornPop
      @TheRealCornPop 4 месяца назад

      And now your vendor locked in to Turso when you could have just used Postgresql

    • @vivekseth3210
      @vivekseth3210 2 месяца назад +1

      You are correct. If you use SQLite, you cannot have 2 servers talk to the same database.
      The vast majority of applications will work just fine with 1 server, and can use vertical scaling to avoid performance issues. If your use-case absolutely needs >1 server, than sqlite might not be the right fit for you.

  • @hbobenicio
    @hbobenicio 3 месяца назад

    I got curious on the reasoning about disabling THREADSAFE and using ALLOCA (dynamic stack allocation, which is generally a bad idea. that's why linux avoid VLA's, which are just really bad). What about we're on a multithreaded environment and what happens to sqlite it alloca fails?