[ak39]

SQLite not supporting "stored procedures" is a deal-breaker for me. The idea for stored procs is not to "put the process as close to the data" but simply that we have a single place for language-agnostic encapsulation of data procedures.

[bob1029]

SQLite supports the best version of "stored procedures", IMO:

https://www.sqlite.org/appfunc.html

[chungy]

SQLite is an in-process database. If you need language-agnostic encapsulation of data procedures, SQLite is not for you. I would suggest you consider PostgreSQL.

[ketralnis]

I don't think I've ever needed language-agnostic procedures in a project where sqlite is also a fit. I like them both but at different times. I'd love to hear your use case though. Do you have microservices in different languages running on the same machine that share a db file? Or maybe a web + command line interface?

Sqlite's internals actually could support something like this: it has a bytecode engine https://www.sqlite.org/opcode.html that's more oriented around executing query plans and it's missing some pieces (e.g. it has no stack, only registers) but much of the machinery is there to expand it to stored procedures

[pstuart]

What language(s) would the stored procedures be, and how would that look in keeping with the ethos of the project?

Their reasoning for not doing this is not unreasonable, but it certainly would be cool if such functionality existed.

[chasil]

The language for triggers in SQLite appears to be a fragment of SQL/PSM and Oracle PL/SQL.

Perhaps this will grow into a more thorough implementation.

[hahn-kev]

But man the maintenance and debug nightmare never seems worth it for that tradeoff. Not to mention vendor lockin