Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"SQLite is not designed to replace Oracle. It is designed to replace fopen()."

sqlite.org

Post reply on HN
Print view View original

31–40 of 58 posts

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#31

Post by pilif »

kellishaver wrote: post #18
DNeb wrote: post #16

Earlier quoted context omitted.

Agreed. And the database can grow surprisingly large (multi GB with many millions of rows) and it still performs quite well.

This surprises me. Though I've used it with great success for several small projects, my only experience with SQLite on anything remotely large was a Rails app with maybe a million records in the DB. Over time, performance became very slow and switching to MySQL made a world of difference. At the time, I attributed it to SQLite, but now I'm wondering if it was Rails or (more likely) my inexperience at optimizing perf…

Write operations to a SQLite file lock the whole file. It's possible that your rails app had enough users doing enough writes so that the processes had to constantly wait.

As long as you are the only user, performance should be constant regardless of file size (minus fragmentation issues)

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#32

Post by bdunbar »

derrickpetzold wrote: post #21

Can anyone say when Oracle is justified? I have yet to encounter a problem the postgres or mysql didn't support but alas I have not worked on everything.

Can anyone say when Oracle is justified?

When the ERP application you are installing has in it's specs

- Supported database: Oracle

I am sure a crack Postgres guy can bash and file that sucker to work. But the vendor will not support the result, and some places, some situations, that really counts for a great deal.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#33

Post by karambahh »

jodrellblank wrote: post #26
derrickpetzold wrote: post #21

Can anyone say when Oracle is justified? I have yet to encounter a problem the postgres or mysql didn't support but alas I have not worked on everything.

When you need "nobody ever got fired for buying IBM" levels of nontechnical legitimacy? (I too wonder what technical marvels it can perform which justify the cost).

When you need multiple spatially distributed active/active write nodes (multiple masters...) you pretty much need Oracle RAC. When confronted with the cost, you end up designing something where writes are pushed to a caching layer, which deals with an active/passive setup, with enough buffer to switch passive to active if something goes wrong.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#34

Post by jacques_chester »

karambahh wrote: post #33
jodrellblank wrote: post #26

Earlier quoted context omitted.

When you need "nobody ever got fired for buying IBM" levels of nontechnical legitimacy? (I too wonder what technical marvels it can perform which justify the cost).

When you need multiple spatially distributed active/active write nodes (multiple masters...) you pretty much need Oracle RAC. When confronted with the cost, you end up designing something where writes are pushed to a caching layer, which deals with an active/passive setup, with enough buffer to switch passive to active if something goes wrong.

DB2 and Teradata boast comparable degrees of horizontal, multi-site scalability.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#35

Post by alastairpat »

reduxredacted wrote: post #8

By the use of "an", I learned that I have been pronouncing SQLite wrong. The maintainers clearly prefer the spelling out of SQL in the title. I've always been on the "sequel" side of pronouncing SQL (hey, it's no worse than "scuzzy" for SCSI), which morphed SQLite into "Sequelite". I never realized how bizarre that sounded (almost more like a material than a database).

From what I can understand, that's actually a difference between Commonwealth and American English.

I'm Australian and always spell out acronyms when speaking them - saying something like 'sequel' or 'scuzzy' just sounds weird to me.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#36

Post by k33l0r »

Muzza wrote: post #27
MostAwesomeDude wrote: post #25

Earlier quoted context omitted.

As an aside, to follow Linus' pronunciation, it is Lee-nucks, from the Finnish way of pronouncing "Linus." Americans are used to a different pronunciation of the same name and thus generally adopted a different way of saying "Linux." Language is fascinating!

Linus is a native speaker of Swedish, not Finnish.

The pronunciation of 'Linus' is pretty much the same in Swedish and Finnish, though.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#37

Post by apl »

techtalsky wrote: post #7

Even though SQLite isn't designed to replace Oracle, I'm certain there's plenty of companies that have purchased expensive Oracle licenses for projects where SQLite would have worked perfectly well. I've often used it for web-based custom CMS's of one kind or another where many people would have used MySQL and the client would never know the difference. I'm sure many people have used Oracle for web-based internal too…

Regardless of how much fun lamenting the assumed technical incompetence of enterprise software development can be, I strongly doubt that this has ever happened. Oracle is very expensive, and SQLite is very limited outside its clearly delineated use cases.

Oracle versus PostgreSQL or possibly MySQL -- maybe. But don't think Oracle sells snake juice; their reporting tools, for instance, are top-notch and way beyond what the open source world can provide.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#38

Post by techtalsky »

apl wrote: post #37
techtalsky wrote: post #7

Even though SQLite isn't designed to replace Oracle, I'm certain there's plenty of companies that have purchased expensive Oracle licenses for projects where SQLite would have worked perfectly well. I've often used it for web-based custom CMS's of one kind or another where many people would have used MySQL and the client would never know the difference. I'm sure many people have used Oracle for web-based internal too…

Regardless of how much fun lamenting the assumed technical incompetence of enterprise software development can be, I strongly doubt that this has ever happened. Oracle is very expensive, and SQLite is very limited outside its clearly delineated use cases. Oracle versus PostgreSQL or possibly MySQL -- maybe. But don't think Oracle sells snake juice; their reporting tools, for instance, are top-notch and way beyond wha…

Believe me, I wasn't trying to have fun at someone's expense. I think factors other than incompetence can account for this, like just simple ignorance.

I was more speaking to how easy it is to underestimate SQLite's flexibility and power and not realize how wide its use case actually is.

Of course for many use cases Oracle's tools are the best choice, but SQLite can handle quite a serious dataset in some use cases. A million records sounds like a lot. I can easily imagine crews used to working with Oracle using it for project far below its ideal capacity when they can buy licenses on a big corporate account.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#39

Post by petercooper »

reduxredacted wrote: post #8

By the use of "an", I learned that I have been pronouncing SQLite wrong. The maintainers clearly prefer the spelling out of SQL in the title. I've always been on the "sequel" side of pronouncing SQL (hey, it's no worse than "scuzzy" for SCSI), which morphed SQLite into "Sequelite". I never realized how bizarre that sounded (almost more like a material than a database).

Just in case anyone cares because I did the research on this a few weeks ago (including watching its creator say it numerous times) it's S-Q-L-Lite. Yeah, that seems like a duplication of the L but there you have it.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#40

Post by brazzy »

kellishaver wrote: post #18
DNeb wrote: post #16

Earlier quoted context omitted.

Agreed. And the database can grow surprisingly large (multi GB with many millions of rows) and it still performs quite well.

This surprises me. Though I've used it with great success for several small projects, my only experience with SQLite on anything remotely large was a Rails app with maybe a million records in the DB. Over time, performance became very slow and switching to MySQL made a world of difference. At the time, I attributed it to SQLite, but now I'm wondering if it was Rails or (more likely) my inexperience at optimizing perf…

It depends a lot on the complexity of queries.

Implementing a B-tree is not easy but no black magic either (I did it for my diploma theses). Same for a hash join. And these two things are really all you need to have reasonable performance for simple selects and joins on tables of almost any size.

But if your queries get more complex, the query execution plan starts to make a huge difference - and a query optimizer is black magic, as anyone who's wrestled with Oracle's can attest. I doubt SQLite can compete in that area.

Post reply on HN