Why I Choose PostgreSQL Over MySQL/MariaDB

Nerval's Lobster writes For the past ten years, developers and tech pros have made a game of comparing MySQL and PostgreSQL, with the latter seen by many as technically superior. Those who support PostgreSQL argue that its standards support and ACID compliance outweighs MySQL's speed. But MySQL remains popular thanks to its inclusion in every Linux Web hosting package, meaning that a mind-boggling number of Web developers have used it. In a new article, developer David Bolton compares MySQL/MariaDB 5.7.6 (released March 9, 2015) with PostgreSQL 9.4.1 and thinks the latter remains superior on several fronts, including subqueries, JSON support, and better licensing and data integrity: "I think MySQL has done a great job of improving itself to keep relevant, but I have to confess to favoring PostgreSQL."

Comments

I choose MS SQL Server

[Anonymous Coward]

Best of all worlds. And guess what, in the grand scheme of things, the price is a drop in the bucket compared to salaries.

Re:I choose MS SQL Server

[Anonymous Coward]

MS SQL server has its place:

1: Oftentimes a company already has it licensed, so might as well use it.

2: It is auditor friendly, with the pieces of paper (FIPS, etc.) that don't mean much in real life, but do mean a lot when ISO, or other audits happen, and you have to justify your existence and design decisions. (For those who say certificates/certifications don't matter, one place I worked actually had auditors that would fire people on the spot for "failing to have authority to run the equipment" if their RHCE/MCSE/CCIE certs lapsed.)

3: Finding MS SQL expertise is easy.

4: MS SQL does work and is decently secure. For 99.99% of tasks, it is just as good as Oracle.

This isn't to say that PostgreSQL is bad... but there are times where MS SQL is the ideal choice.

Re:I choose MS SQL Server

[Anonymous Coward]

In terms of licensing, I think the MS sales force is learning too much from Oracle. We are backing out from supporting MS-SQL due to the insanely expensive licensing terms for deployments that MS sales is starting to apply to it.

Re:I choose MS SQL Server

[Foofoobar]

Yeah and it runs GREAT on Linux. Like a rock.

Re:I choose MS SQL Server

[neminem]

More like for 100% of tasks. MSSQL is pretty good; a bit of a pain to install, and obviously crazy pricy unless you're just already paying for it for some other reason, but it's plenty powerful and pretty simple to use.

Oracle, on the other hand, is a steaming pile of turd.

Re:I choose MS SQL Server

[Gr8Apes]

MS SQL server has its place:

Our competitors or enemies servers? A trashcan?

1: Oftentimes a company already has it licensed, so might as well use it.

Lemmings....

2: It is auditor friendly, with the pieces of paper (FIPS, etc.) that don't mean much in real life, but do mean a lot when ISO, or other audits happen, and you have to justify your existence and design decisions. (For those who say certificates/certifications don't matter, one place I worked actually had auditors that would fire people on the spot for "failing to have authority to run the equipment" if their RHCE/MCSE/CCIE certs lapsed.)

Sounds like a thankless place to work, but still doesn't support using MS SQL.

3: Finding MS SQL expertise is easy.

citation? Finding people who have seen MS SQL is easy, finding expertise, however, is as much or more limited than for other systems, mainly because most with real expertise won't touch MS SQL except when the business end of a pointy stick is poking them in the eye.

4: MS SQL does work and is decently secure. For 99.99% of tasks, it is just as good as Oracle.

This isn't to say that PostgreSQL is bad... but there are times where MS SQL is the ideal choice.

MS SQL barely works, and falls over as soon as it is hit with significant load. It's an old massive pile of crap essentially given to MS by Sybase, who mistakenly didn't believe anyone would be stupid enough to continue using that smelly pile when their new database was released. They severely underestimated MS's marketing prowess in this regard, and someone like you (an AC no less!!!) propagates the continuation of this incredibly terrible solution.

Re:I choose MS SQL Server

[Richard_at_work]

The Express Edition of MS SQL Server is pretty damn good for 99% of the deployments you would consider MySQL for, and its free. The limits are memory usage (1GB per instance), database size (10GB), CPU (1 physical or 4 cores) and instances (50 per server).

That should run most websites and business apps fine. Because most websites and business apps are drastically overspecced and under used.

Re:I choose MS SQL Server

[DarkOx]

Was the last version of SQL Server you used 7.0 or something. I love to dump on Microsoft as much as the next guy, but honestly SQL Sever 2000 on is pretty damn good. As far as falling over when hit with significant load, I was running a 60TB database on the first Itanium versions of SQL 2000 back in '04 and it never 'fell over'.

The project was big enough and cost enough Microsoft was willing to send people out to help us tweak and tune. That is all we did though nothing exotic like a custom build or anything. Just end user tuneables and guidance on schema around partition views and like.

So really there are plenty of legitimate criticisms of the Microsoft platform family but SQL Server falling over ain't one of them.

Re:I choose MS SQL Server

[jedidiah]

> 3: Finding MS SQL expertise is easy.

No. Not really. Microsoft pushes the idea that you don't need to have any clue to use it's products. It helps enable this idea with better novice interfaces. This leads to the problem that you end up with barely trained monkeys having the appearance that they can us Microsoft products.

> 4: MS SQL does work and is decently secure. For 99.99% of tasks, it is just as good as Oracle.

I think Microsoft has the only RDBMS that ever had a genuine viral exploit in the wild. That's quite an accomplishment. SQL Server also has some "subtleties" that make it oddly more user hostile than even Oracle.

Re:I choose MS SQL Server

[bad-badtz-maru]

It's not cheap at all once you get into even just medium-scale usage. If you have a situation where you are starting out small but plan to grow, you need to really consider whether it's wise to go with a commercial RDMBS, because the pricing does get nasty when you get to the point of needing clusters, high core counts, and standby sites.

Re:I choose MS SQL Server

[jedidiah]

So? There's a free version of Oracle too, if you are willing to expose yourself like that.

"Getting something for nothing" usually isn't the point of using "serious commercial enterprise software".

Non-free Oracle can even be licensed in ways that make it as cheap as a more expensive consumer application.

Re:I choose MS SQL Server

[MightyMartian]

Translation: It has limits that renders it useless on production servers.

Re:I choose MS SQL Server

[MightyMartian]

There's this little matter of having to run Windows. Not very bloody useful, particularly on production servers, unless you want to a. buy a Windows Server license ($$$) and SQL Server licenses ($$$).

Whereas I can install a Linux or BSD server, throw PostgreSQL or MySQL on it and the cost is the hardware and my time. If I need to add more infrastructure, again it's my cost and my time.

Re:I choose MS SQL Server

[Gr8Apes]

I've had the misfortunate to work with 2000, 2005, 2008 and 2008 R2, and 2012, and every single one of them has failed spectacularly, many of them with the same basic issue, that wonderful escalating locks problem, which MS spins as a "performance improvement" much like driving a bus off a cliff improves its performance, and in much the same way.

Re:I choose MS SQL Server

[phantomfive]

I don't know, in my experience, I rank it like this:

1) Postgresql - full of random features that makes things easier and better (you can use almost any language for stored procedures, for example. Not huge, but nice).
2) MS SQL - Works fine, not too interesting.
3) MySQL - full of random feature that makes things harder (do you know you can't rollback a transaction that modifies a table? Every other database can....).
4) Oracle - Has all the features, but some of them have very funky syntax.

-- -- -- -- -- --

If you support using the 'best tool for the job,' then the choice is obvious, following this algorithm:
1) If you're using a Microsoft stack, use MsSQL (I've tried using entity framework with MySQL....it mostly works, but it's a pain).
2) If you're using a stack that integrates well with MySQL, use MySQL.
3) If you are in desperate need of corporate CYA, use Oracle.
4) For anything else, use Postgresql. You won't regret it.

Re:I choose MS SQL Server

[WaffleMonster]

I've had the misfortunate to work with 2000, 2005, 2008 and 2008 R2, and 2012, and every single one of them has failed spectacularly, many of them with the same basic issue, that wonderful escalating locks problem, which MS spins as a "performance improvement" much like driving a bus off a cliff improves its performance, and in much the same way.

If lock escalation is your problem then lock escalation isn't the problem.

Re:I choose MS SQL Server

[phantomfive]

No, you misunderstood what I wrote. I was referring to the fact that MySQL DDL is not transactional. So if you run an 'alter table' command, don't expect to be able to roll it back. Seriously though, even SQLite offers this feature, so MySQL is just a dunce.

The main difference that I see is that Postgres fans generally have the same zeal and lack of experience that Rails fanboys exhibit. I am not sure where you fall but you are doing a disservice to our community by spouting false claims when you do not understand what you are talking about. (That sounds like a rails fanboy to me.)

I'm pretty sure it means you're a moron. Or rather, you should have thought a little before spouting insults.

Re:I choose MS SQL Server

[DogDude]

the pricing does get nasty when you get to the point of needing clusters, high core counts, and standby sites.

If you're doing something that data intensive and can't afford a DB license, then you're doing something wrong.

Re:I choose MS SQL Server

[RoLi]

If you're doing something that data intensive and can't afford a DB license, then you're doing something wrong.

The sheer stupidity in that statement is outrageous. You may not believe it, but it's not just Fortune 500 companies that do "data intensive" stuff. Even a freelancer (i.e. a single person) is able to do "data intensive" stuff.

So, whether you can "afford" a DB license depends on the application. There are lots of applications where using DB would price you right out of the market.

Re:I choose MS SQL Server

[RoLi]

(un)paid advertizement:

I love to dump on Microsoft as much as the next guy, but honestly SQL Sever 2000 on is pretty damn good.

Now, if SQL server is "honestly" so good, why are the one million busiest sites slowly migrating away from Microsoft?

http://news.netcraft.com/archi...

In 2008, 20% of the million busiest websites used Microsoft, now only 12% do, and the decline slowly continues.

When we talk about these installations, we talk about very heavy loads, very much data and very high requirements on reliability and availability.

So why does the high-end "enterprise" systems move away from that "pretty damn good" platform? The Microsoft apologists on this thread constantly tell me who licensing costs don't matter and how good all Microsoft products are ("honestly"!) - but exactly in the one area where licensing costs really don't matter (the one million busiest sites) Microsoft is also losing it. So why then?

Maybe it's not as "pretty damn good" as some anonymous internet commentators claim? Honestly?

Re:I choose MS SQL Server

[Fallso]

Then run it in AWS or another cloud if you want the cheap option.If you're crunching data 24/7 and still can't afford that licensing structure, you really are doing something wrong.

Re:I choose MS SQL Server

[bad-badtz-maru]

Just the wording "a DB license" leads me to believe your exposure is with smaller companies and smaller datasets. Have you ever priced a single 32 core Oracle installation with the data warehousing option enabled? If it's a business of any size, you'll need to cluster for reliability, so multiply that single license out. And if it's a publicly traded company, you'll probably need an offsite standby cluster. Even though it sits there and does nothing 24/7, the licensing fee for the standby cluster will be the exact same price as if it was the primary. Also, don't forget dev and testing environments, those aren't free.

Not every large company is a high-margin high tech company. The retail sector, for example, has mountains of data and relatively low margins. DB license expense can be a big concern.

Re:I choose MS SQL Server

[aralin]

It is. We all here have 15 years of experience with Microsoft as the Devil and this makes it hard to ever trust them again. Because we did trust them and trust them again and again and again and every single freaking time, they've done something so horrible to break this trust that our very souls have felt like burning in hell.

Re:I choose MS SQL Server

[TechyImmigrant]

If the business got that big, I'd be hiring people to do it for me and there would be some benefits to using more standard approaches since getting people who think like I do would suck and it would suck for employees to have to follow their boss's crazy ideas on the right way to make a responsive database for a point of sale environment.

But there's nothing preventing an in-memory database being duplicated, load balanced, redundantized (or whatever the right word is for adding redundant mirror servers) etc. In fact the consistency transactions are easier because the parties are algorithms talking to each other, rather than algorithms talking via a storage medium. You would have to write it yourself though since the world still seems to have a hard on for SQL long after they left Cobol behind, which is bad for the same reasons. In a point of sale situation, the order of transactions is not that important except for specific things, like you can't return an item before you've purchased it. So it's easy to post-hoc order the transaction log, a bit like the bitcoin block chain, where the current head of the list is indeterminate, but it's resolved a few steps back.

My issue isn't with disk vs. memory. That's a normal tradeoff. My issue is with SQL, which is horrible in every way that an insecure, computationaly undecidable lump of middleware can be.

Re:I choose MS SQL Server

[Hognoxious]

It also, quite amusingly doesn't come pre tuned to handle Oracle databases.

It's possible that your usage is atypical. It's also possible that Oracle are happy to charge you 2k bucks a consultant-day for "customisation".

Let's balance the hypotheticals with some actuals. One, Larry likes yachts. Two, yachts don't buy themselves.

Duh

[Anonymous Coward]

Who trusts MySQL with important data? No one who knows about PG. Good web frameworks like Django prefer PG, while crap ones like Drupal and other PHPtards prefer MySQL.

At least

[Anonymous Coward]

It's not Access

Re:At least

[HornWumpus]

If Excel is using the old jet engine you get both in one deal.

The worst stack I've ever seen. ASP invokes Access (via OLE automation) which in turn calls FORTRAN. I will smoke a turd in purgatory for showing them how to invoke Access.Application from VB.

I quit in disgust shortly after. 'They' were supposed to define an API without knowing it, so we could replace the Access part. Management said: 'It's working, great lets move forward.'

A more intringuing question...

[leonbloy]

would be why I still choose to read Slashdot instead of ... anything else.

Let me quote, from the comments thread at a recent article by same submitter:

Could we stop having Dice articles submitted by Nerval's Lobster? Why not fully disclose that the story was submitted by the corporate parent of Slashdot?

Another user, in the same thread, had speculated:

What comes next, a thread on "is Emacs better than Vi"?

No, sir, you were utterly wrong. It came "Postgresql is better than Mysql".

Re:A more intringuing question...

[tbuddy]

Totally came to the thread for this. Was hoping to have someone rant that Postgre was for hipster rails developers, but comments are pretty early.

This guy should really update his website to say Postgre is superb

SQLite3

[fyngyrz]

And for many tasks, you don't need any of that. Have a look at SQLite3 (also, it's built into Python, which can be handy.)

Worried about stability? You can compile the SQLite3 source code right into your project. That way, your databases always match your shipping product, indefinitely, period.

It's not usable for everything -- only a decent subset of SQL is supported -- but you might be surprised at just how much is there, and working well.

Re:SQLite3

[Bacon Bits]

SQLite3 is a fantastic product, but it's primarily intended as an embedded SQL database, not an RDBMS. They're not really intended to do the same things.

On the other hand, at least SQLite doesn't "feature" silent non-deterministic aggregates.

Postgres hands down

[infernalC]

I come from a Sybase SQL Anywhere shop. It never ceases to amaze me how stuff that can be elegantly expressed in a couple of queries in Watcom-SQL typically takes four times as much code in MySQL's dialect. I love Sybase's support for the ANSI standards, subqueries, Java/.NET/C/PHP/Perl stored procedures when they are the right tool for the job (ever needed to resize raster images in an INSERT trigger coming from some third-party application?), and great drivers. I shouldn't have to spend 10 minutes trying to figure out why MySQL doesn't support the standard casting string concatenation operator by default (||), or why subqueries don't work like they ought, etc.

Having used Postgres, all of the worthwhile MySQL features are there, most of the SQLA features are there, and the pain level is much, much lower in Postgres than MySQL for someone coming from a full-featured commercial RDBMS.

What really sucks is all of the applications that are so coded around MySQLisms that they don't run on ANSI-compliant engines.

Re:Postgres hands down

[Bacon Bits]

Instead, the application should be calling *into* the database, not the other way around.

Which is great... until you want two different applications to use the same database at the same time and need to occasionally do the same things the same way. When your data is more complex than what Amazon or Google use and closer to what a hospital information system or school information system use, you can no longer rely on a single application from a single vendor using a single database. Shit ain't that simple anymore.

Re:Postgres hands down

[Anonymous Coward]

So your solution, instead of using a proper layer of abstraction (like a service), is to throw everything into the database? Yikes.

The database IS a layer of abstraction.

Re:Postgres hands down

[bad-badtz-maru]

You nailed it. The AC's idea that all data access is performed via a single application is naive. There are cases where the only common interface point between applications is the database.

Re:Postgres hands down

[genkernel]

You, my friend, have never used Microsoft Access

Re:Postgres hands down

[HornWumpus]

It will stop it from working with MySQL.

I thought we were over the whole SQL thing

[i_ate_god]

Isn't everyone all NoSQL nowadays or has that faded away?

Re: I thought we were over the whole SQL thing

[Anonymous Coward]

NoSQL only caught on with dumbasses. Everyone with a brain ignored it.

Re:I thought we were over the whole SQL thing

[ArcadeMan]

Nope, we all moved to XML.

Re:I thought we were over the whole SQL thing

[HornWumpus]

They still use SQL, but only for things smaller then 'web scale'.

Am I joking?

Re:I thought we were over the whole SQL thing

[new_01]

NoSQL has its use cases. But the fact that NoSQL lacked mature ACID compliance meant that many of the large companies who relied on certifying data integrity (think bank transactions and other large companies for which standard relational databases already provided them with safe transactions out of the box) couldn't switch over to it. "NewSQL" is the latest buzzword that is going around. They're finding that heavily modifying the database to fit into the distributed world is better than dropping SQL and ACID altogether. Maybe it's better to maintain integrity in the database itself rather than forcing developers to do it in the application layer. At least that's what I got out of reading through Google's paper on F1.

Re:I thought we were over the whole SQL thing

[Anonymous Coward]

I moved all my XML into JSON, then stored it in a MySQL table named "JSONXML" with a single column named "data". I call it "web 3.0 agile database". I'm in the process of writing a manifesto and bunch of books about it.

Re:I thought we were over the whole SQL thing

[angel'o'sphere]

You likely are joking :)

Because the term 'web scale' has no meaning at all ...

Re:I thought we were over the whole SQL thing

[angel'o'sphere]

The point is not to switch over to NoSQL, but to use it where it has its benefits.

90% of the data in our days does not need 'integrity constrains' or even transactions.

RDBS are abused for everything because developers are to stupid to realize when a simple file is sufficient. Or their managers ... or what ever.

Everytime I see someone 'logging' intoma database I like to carry him into the base,ent and chain him onto a wall.

Some old quotes...

[mi]

Those who support PostgreSQL argue that its standards support and ACID compliance outweighs MySQL's speed.

One expression I remember seeing on the topic went something like: "I can make it as fast as you want as long as it does not have to actually work". The conversation was about filesystems comparing (the non-complying) async-mode with the safer (but slower) alternatives, that actually stood by the promise of fsync(2).

And another, more modern idea (only about 10 years old) quote is "Object/Relational Mapping is the Vietnam of Computer Science". Which, for the purposes of TFA, may be interpreted as something like "who cares for ACID compliance — we can deal with occasional data-corruption and inconsistencies — just make it fast in the usual case".

I rather doubt, we'll settle the question in this discussion...

Postgres has referential integrity

[Scott.Simpson]

The MOST important reason for using Postgres is that it has object ids (OIDs). This allows true referential integrity. You can have a row point at another row and this reference stays the same REGARDLESS of whether you change the primary key of the referenced row. This allows true object orientation.

Re:Postgres has referential integrity

[rycamor]

That's not even close to what "referential integrity" means. In fact, it could be used to accomplish quite the opposite.

OIDs are one feature of PostgreSQL that should be buried inside the implementation and not allowed to be accessed from the developer side. Otherwise you are pretty much completely going around the whole point of the Relational Model. If you are developing an application in such a way that it needs pointers to rows, you might as well just store data on the filesystem and be done with it. Or use one of those fancy NoSQL thingies and enjoy your data corruption.

In my experience

[Trailer Trash]

And I'm probably going to step on a lot of toes here, but people like me strongly prefer Postgres to MySQL. And by "people like me" I mean folks for whom their first real rdbms experience was theoretical or "commercial". I did both.

I used ingres in college to a small extent and then the Ingres commercial product for years after that. I have also used Sybase and Oracle professionally. PostgreSQL easily walks among the giants of that industry.

Every time this discussion comes up the MySQL side has to say "yeah, but..." about a thousand times. MySQL doesn't do ______ properly? "Yeah, but if you just install this other piece of software and change a couple of config files it *can* do it.' Well, con-fucking-gratulations!

The point is that PostgreSQL does exactly what it should do out of the box. I don't have to change a configuration file to make it ACID compliant, fast, correct, whatever. It just works and works correctly out of the box.

Every time someone tells me how easy MySQL is to set up they've betrayed their experience level in this realm.

I know a lot of you are going to mod me down - I don't care. But why not reply instead?

Re:In my experience

[Anonymous Coward]

Exactly! It's always blown my mind how much genuinely important functionality MySQL zealots are willing to do without in the name of simplicity. It really lets me know how little experience that have with genuinely mission-critical systems, or how small the environments they've worked in are.

I absolutely think MySQL has its place, primarily as a support DB for web frameworks - but honestly that's mostly just because it's so firmly entrenched there that I long ago gave up trying to suggest that the developers make their systems more database agnostic (plus, the work to do so would be better spent on making those frameworks less of a pain to wrangle, from what the PHP developers I know tell me).

When I need to keep a system stable, and ensure that things as important as say, financial transactions don't get messed up by silly things like improperly handling transactions or some other thing MySQL is stamping its feet about staying on the hobbyist side of things for, it's a no brainer to me. Plenty of people will preach the benefits of a commercial vendor (mostly just because it makes passing the legal hot potato easier if you really screw up customer data - the issue of support should be a no brainer with how many consultancies are out there, if you happen to somehow hire a total dullard as your DBA), and for them there's EnterpriseDB - a commercially produced and supported version of Postgres.

What's more, Postgres completely blows the doors off of most other platforms. I've worked with production data in tables with up to a billion rows (yes, that one should've been in hadoop, but that wasn't a very agile company, and honestly it's a bit silly to setup hadoop for one table out of about 1200 they used), where MySQL would've been completely out of its element, and Postgres handled the load just fine (mind, querying against a billion rows on ANY RDBMS requires carefully crafted queries if you're going to avoid bogging down production). In data warehousing, the company needed that same data set (admittedly aggregated via ETL) in a proper EDW for consumption in their BI presentation tools. Our ETL tool was capable of outputting to multiple output sources very easily, and at one point I was tasked with deciding which platform was the best (we had Postgres, MS-SQL and Oracle servers, all tuned for peak performance). Long story short in terms of the ETL done, the output data set was say, 80 million rows or so to the fact table. Postgres was, by a large margin, the fastest to finish writing the data - and it did so on the smallest hardware. Oracle took almost an additional 30 minutes to complete the load. MS-SQL was behind by a margin I honestly don't recall. This was basically a debate between myself and the CIO about whether Postgres or Oracle should be our EDW platform, so I didn't commit the gap to memory.

When it came time to query against the data for BI, Postgres 9.1 was 10-15% faster than Oracle (mind, this is with half the CPUs/cores, and 1/8 the RAM of the Oracle box, which had been tuned by a BI consulting firm specifically for BI/OLAP performance). When tested against Postgres 9.2 (which added the benefit of index-only scans), the Postgres box was easily 25-30% faster than the Oracle box, at its slowest.

Most of the people who champion MySQL have never worked with a data set like that, so I don't hold their naivete against them, but it's cute to hear them go on about how clunky and difficult Postgres is...

Bottom line

[sjames]

In the beginning, Postgress set out with correctness as the primary goal. Whatever it did, it had to do it correctly. It started life on the slow and resource hungry side. MySQL set out to be fast and more or less correct in the common case. Back in the '90s that made a lot of sense for small servers.

In the decades since, servers have gotten bigger and Postgress got fast and efficient while still being correct. Why would I want to incur a performance penalty in the surrounding software to check behind the database to make sure it didn't just scrag my data?

Re:Someone chose PostgreSQL for their use case

[colinrichardday]

no use cases in which we all go into armchair mode and have endless debates already hashed out a million times over.

Yes, this is slashdot.

maybe, but... probably not.

[fyngyrz]

I've seen cases where the SQLite DB just corrupted itself without any hardware issue or power cycling.

I haven't -- I've seen cases where the filesystem corrupted itself (with or without the help of hardware failure, no idea), but I've used SQLite most extensively (seriously, I bet I'm close to having used every feature in the thing) in its various revisions for years, as have tens of thousands of my users consequent to my incorporation of same, and I've heard of, and experienced, exactly zero events of DB failure (and one of my most popular apps would have crapped itself and gone blind if such happened, so I'd surely have heard about it.)

Also, different app (SdrDx), but I use it the other way around here; I've got an SQLite DB on my website that tracks startups of the code as to version, revision, step, beta status, platform (windows, OSX), time, date and IP, as part of the handshake that lets the users know if there are any upgrades (in-app title bar notification, nothing invasive.) This lets me keep track, somewhat, how many people are using what version of the app. SdrDx is well over 15 thousand regular users, many more that aren't regular, and the DB is moderately busy as a result, again, no problems. The writes to this particular DB are pretty straightforward, but the queries I've written for it span a decent range of futzing about. No problems to date. Of course it's backed up, but no need for a backup as yet.

I'm also presently using it, again extensively, in an incomplete, but complete enough for my day to day use, DSLR application of mine, code compiled in, along the lines of Lightroom and Aperture, and again, zero DB failures of any kind. Oodles of DB activity for every image, every library op, every bit of auto-categorizing, library backup, tagging, annotating, posted-to recording, flagging, versioning, plug-in and plug-in settings recording, and so on.

So I'm going to go with... possible, but even slightly likely. Also, any DB can take a crap if the drive underneath it goes bad, or the OS (or some all too clever use of root privs) allows corruption of its storage. None of which should be construed as any kind of criticism of any DB engine subject to the same.

Also, did you report these purported corruption events to the author of SQLite? Sure hope you did. :/

Nerval's Lobster Advertising Service

[edibobb]

Nervals Lobster's last 15 posts have been links to news.dice.com, the parent company of Slashdot. They're nothing but ads.
[Add obligatory Slashdot's-going-to-hell-in-a-handbasket slam here.]

Re:JetProfiler is why you should use MySQL

[plopez]

see http://www.postgresql.org/docs...

Just about every modern DB engine has something like it. If you are not even aware of it you should really learn more of your tool set.

200 comments

[Hognoxious]

200 comments and nobody has asked whether it's webscale or not. This place is going to the dogs already.