5 ms·

- Why not? https://www.sqlite.org/appfileformat.html https://www.sqlite.org/appfileformat.html - Its size is less than a megabyte: https://sqlite.org/footprint

by jve 3y ago

- Why not? https://www.sqlite.org/appfileformat.html https://www.sqlite.org/appfileformat.html - Its size is less than a megabyte: https://sqlite.org/footprint.html https://sqlite.org/footprint.html - 750KB if all features are enabled: https://www.sqlite.org/about.html https://www.sqlite.org/about.html - Looks like fair amount of functionality can be left out when compiling sqlite and with options to influence/strip down query planner: https://www.sqlite.org/compile.html https://www.sqlite.org/compile.html - And "SQLite does not compete with client/server databases. SQLite competes with fopen()": https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html In the end, you don't need a database, but a library that gives you database API and behavior.

Ensorceled 3y ago
The complaint is not “it isn’t good” but rather “it is not replaceable”. Since SQLite is so powerful, once you specify it as a format, you are stuck with SQLite forever.
- ncruces 3y ago
  Which is also "not a big issue", since it's a recommended Library of Congress storage format, and supported long term: https://www.sqlite.org/locrsf.html https://www.sqlite.org/locrsf.html https://www.sqlite.org/lts.html https://www.sqlite.org/lts.html
  - Ensorceled 3y ago
    Which is why I was clarifying the original complaint and not supporting the original complaint.
  - 5e92cb50239222b 3y ago
    It is somewhat of a problem: the development team is very small, they don't take outside contributions (so nobody outside the core team really builds up expertise over time), and the vast majority of tests are proprietary. I hope they have a contingency plan just in case (some sort of a dead man's switch that publishes the test suite under a permissible license) as it would probably be quite difficult for others to maintain the same quality without those tests, or re-implement them in a reasonable time frame.
    - floppydiscen 3y ago
      I'm pretty sure this is why libsql was created https://github.com/libsql/libsql https://github.com/libsql/libsql
    - fweimer 3y ago
      But that equally applies to getting critical bug fixes for your particular usage scenario of SQLite. It's not just about the viability as a storage format. For the latter, because the stored data has such a simple format and the implementation has so few dependencies, I expect it will be very easy to get your data out for a long time to come. It's going to be tougher if you have business logic in views or other SQL expressions, of course, and if you rely on SQLite's particular approach to data types (as in “values have types“, but not much more).
- hot_gril 3y ago
  Once you pick ODF as a format, you're stuck with it forever... except I wouldn't categorize it as powerful.
deleted 3y ago
[deleted]
orf 3y ago
> In the end, you don't need a database, but a library that gives you database API and behavior. Why do you need a single library that gives you a database API and behaviour? Wouldn't it be better to decouple those: provide an open, standard format that enables compact, fast, structured storage that is built to allow transaction/atomic updates. If that exists then you can plug sqlite on top of that, or something else. Because you don't _need_ any of SQL, or really sqlite to improve the OpenDocument format. You need the storage format. OpenDocument is very different from the pretty scientific/niche/highly-vendor-locked examples given in replies by others here. Locking this into a format developed by essentially a single person with a single implementation is absolutely mad. But... it's less mad if the file format wasn't coupled to sqlite.
- nurbl 3y ago
  A great thing about just using sqlite as the format is that you get lots of potential features. Sure most applications don't need full SQL power just to save and load data. But then at some point you might want more advanced functionality, or migrate to a new structure. And both you and your users get tools for free, e.g. to extract data or fix problems, or just look around. Other applications can quite easily read your files, without you needing to write various language libraries. Very few projects get around to building that kind of tools for their made up format. I could agree about the single implementation, but if the alternative is making something new up I am not sure in what way that would be better.
- colonwqbang 3y ago
  The Sqlite format is open and the spec is here: https://www.sqlite.org/fileformat2.html https://www.sqlite.org/fileformat2.html I haven't studied the spec in detail but it seems comprehensive. The fact that there also exists a high-quality, stable, public domain reference implementation can't really be counted against the format, can it?
- hot_gril 3y ago
  > Wouldn't it be better to decouple those: provide an open, standard format that enables compact, fast, structured storage that is built to allow transaction/atomic updates. The high-level software abstraction approach doesn't hold up when it comes to databases. This is such a wide and performance-critical interface that any abstractions are gonna leak badly. Even the SQL standard has all these impl-specific flavors. Many have tried to build layers on top that'll work with multiple DBMSes, and it's never worth. Anyone writing an app backend is just gonna marry a particular DBMS for the performance benefits (puns intended). If for some reason an alternative implementation really needs to exist, SQLite is simple and open enough that someone can do it.

by jve 3y ago

Ensorceled 3y ago

The complaint is not “it isn’t good” but rather “it is not replaceable”. Since SQLite is so powerful, once you specify it as a format, you are stuck with SQLite forever.

ncruces 3y ago
Which is also "not a big issue", since it's a recommended Library of Congress storage format, and supported long term: https://www.sqlite.org/locrsf.html https://www.sqlite.org/locrsf.html https://www.sqlite.org/lts.html https://www.sqlite.org/lts.html
- Ensorceled 3y ago
  Which is why I was clarifying the original complaint and not supporting the original complaint.
- 5e92cb50239222b 3y ago
  It is somewhat of a problem: the development team is very small, they don't take outside contributions (so nobody outside the core team really builds up expertise over time), and the vast majority of tests are proprietary. I hope they have a contingency plan just in case (some sort of a dead man's switch that publishes the test suite under a permissible license) as it would probably be quite difficult for others to maintain the same quality without those tests, or re-implement them in a reasonable time frame.
  - floppydiscen 3y ago
    I'm pretty sure this is why libsql was created https://github.com/libsql/libsql https://github.com/libsql/libsql
  - fweimer 3y ago
    But that equally applies to getting critical bug fixes for your particular usage scenario of SQLite. It's not just about the viability as a storage format. For the latter, because the stored data has such a simple format and the implementation has so few dependencies, I expect it will be very easy to get your data out for a long time to come. It's going to be tougher if you have business logic in views or other SQL expressions, of course, and if you rely on SQLite's particular approach to data types (as in “values have types“, but not much more).
hot_gril 3y ago
Once you pick ODF as a format, you're stuck with it forever... except I wouldn't categorize it as powerful.

deleted 3y ago

[deleted]

orf 3y ago

> In the end, you don't need a database, but a library that gives you database API and behavior. Why do you need a single library that gives you a database API and behaviour? Wouldn't it be better to decouple those: provide an open, standard format that enables compact, fast, structured storage that is built to allow transaction/atomic updates. If that exists then you can plug sqlite on top of that, or something else. Because you don't _need_ any of SQL, or really sqlite to improve the OpenDocument format. You need the storage format. OpenDocument is very different from the pretty scientific/niche/highly-vendor-locked examples given in replies by others here. Locking this into a format developed by essentially a single person with a single implementation is absolutely mad. But... it's less mad if the file format wasn't coupled to sqlite.

nurbl 3y ago
A great thing about just using sqlite as the format is that you get lots of potential features. Sure most applications don't need full SQL power just to save and load data. But then at some point you might want more advanced functionality, or migrate to a new structure. And both you and your users get tools for free, e.g. to extract data or fix problems, or just look around. Other applications can quite easily read your files, without you needing to write various language libraries. Very few projects get around to building that kind of tools for their made up format. I could agree about the single implementation, but if the alternative is making something new up I am not sure in what way that would be better.
colonwqbang 3y ago
The Sqlite format is open and the spec is here: https://www.sqlite.org/fileformat2.html https://www.sqlite.org/fileformat2.html I haven't studied the spec in detail but it seems comprehensive. The fact that there also exists a high-quality, stable, public domain reference implementation can't really be counted against the format, can it?
hot_gril 3y ago
> Wouldn't it be better to decouple those: provide an open, standard format that enables compact, fast, structured storage that is built to allow transaction/atomic updates. The high-level software abstraction approach doesn't hold up when it comes to databases. This is such a wide and performance-critical interface that any abstractions are gonna leak badly. Even the SQL standard has all these impl-specific flavors. Many have tried to build layers on top that'll work with multiple DBMSes, and it's never worth. Anyone writing an app backend is just gonna marry a particular DBMS for the performance benefits (puns intended). If for some reason an alternative implementation really needs to exist, SQLite is simple and open enough that someone can do it.