Oracle vs. PostgreSQL – A Comment
postgresql.org
postgresql.org
- No license fees is huge. My company saves tens of thousands on license fees when we can't really afford it.
- The ability to set up environments super quickly is amazing.
- Rollback of DDLs is huge for testing migrations
- The backup features aren't broken by default. I've spent hours researching how to back up an oracle db and transfer it to another. And at that point versions matter. With postures I think I spent 30 minutes total figuring it out over the years.
Overall I am a huge fan of Postgres having used it for about half of my career and oracle for the other half. I genuinely hope I never use oracle again.
This was an Ivy League university with an endowment in the tens of billions.
I was working with an even worse Oracle product (Hyperion) which had a convoluted homegrown script restarting all of the services on a number of servers to work around their inability to reliably handle database connection failures lasting more than a short interval. Before do that, they’d tried to get rid of the backup window but were told that wasn’t possible unless they could come up with a large amount of money for the license.
Oracle can't roll back these (create table/drop index etc)? That really surprises me. Pretty certain MSSQL can, because I've used it. Amazed, actually, that oracle can't.
Postgres gets it right. DDL is contained in the transacrion until commit.
BEGIN;
DROP TABLE foo;
CREATE TABLE bar (t int);
ROLLBACK;
As far as I know, other than Postgres, only Sybase ASE, Informix, DB2 UDB, and Firebird support transaction DDL.
Postgres, SQL Server, Firebird, DB2, SQLite, Ingres, Informix, Teradata, Vertica all support transactional DDL
The sticker price of the Oracle licence for this would be about $400k a year.
It’s just a complete non-starter for most companies.
It isn't always about affording it, it's about risk reduction, or the perception thereof:
Every single time the company I work for has to renew a license, it has to once again initiate the long, painful process of finding its ass with both hands. "Why are we paying for this? Who exactly is using it? Why are they using it? How much will this cost? Can we make it cost less? Given that it's impossible for us to negotiate this cost, how can we make the company we're licensing it from not charge us as much money as it's inevitably going to? When is this license due? Why hasn't IT, which has no purchasing authority, fixed this yet?"
With Postgres and CentOS and other OSS, none of that happens. The C-levels never know, so they never get a chance to do their headless-chicken dance routine. Much more relaxing.
- Why are you worried about license fees as a developer? :-) Seriously speaking, start with Oracle SE2. It is so cheap, I would use it everywhere. And if you need those "partitioning", "parallel execution" etc - your business is Enterprise, and you can afford such price tags. (I know, there will be a sh1tst0rm now, but please think about what IO said from business POV)
- Oracle Public Cloud gives you database extremely fast - and you will never have issues with license audit
- The name of "Rollback of DDLs" is "no developer access to production" and "UAT" :-)
- hmmm... $> rman rman> connect target rman> backup database plus archivelog delete input; rman> exit
What can be easier?
Are you a huge fan of Vacuuming, XID Freezing, WAL optimisations etc. etc.?
The MVCC in Postgress, in my view (!) is joke from academia, where they had not a single DBA :-)
- Based on its license it's very hard for any one company or individual to "own" Postgres, this makes risk of a company as a bad actor being minimized pretty appealing
- Its geospatial capabilities put it as the most advanced geospatial database, only ESRI software really stands to beat it here
- The improvements for app devs from things like JSON, to a variety of index types put it in unique territory among relational databases
- The extension framework is truly unique and stands to be where a lot of future innovation happens.
Where does PostGIS stand in comparison?
I hate Oracle as much as anyone but this is no longer a fair comparison. If you’re bragging about how good PostGIS is, you’re no longer anywhere near a 66MB install. More like (IIRC) 5 to 10 times that.
I can afford that.
And I think that most people can.
root@pg1:~# LANG=C apt install postgresql-12
Reading package lists... Done
[...]
0 upgraded, 32 newly installed, 0 to remove and 0 not upgraded.
Need to get 59.7 MB of archives.
After this operation, 240 MB of additional disk space will be used.
Do you want to continue? [Y/n] ^C
root@pg1:~# LANG=C apt install postgresql-12 postgresql-12-postgis-3
Reading package lists... Done
[...]
0 upgraded, 105 newly installed, 0 to remove and 0 not upgraded.
Need to get 104 MB of archives.
After this operation, 418 MB of additional disk space will be used.
Do you want to continue? [Y/n]
I know you already know this, but it takes a lot more than just a license. I'd like to call attention to the very enlightened (and noble) work others have done to build a robust political structure and community for Postgres.
The core team, committers and major contributors are spread across many companies and continents. There are different foundations across different regions for handling finances, trademarks, domains, and other basic business operations.
Amazingly, a lot of this structure was being put in place a long time ago, when Postgres was still the weird database option to choose.
And the other one is bribing. From mild to criminal, involving payments via vendors to decision makers - http://allthingsd.com/20120816/oracle-settles-sec-bribery-ca...
The standard license (http://www.oracle.com/technetwork/licenses/standard-license-...) you agree to when you download software from the Oracle Technology Network (OTN) does state that you're not allowed to disclose benchmarks.
You may not:
<<list of things you cannot do>>
- disclose results of any program benchmark tests without our prior consent.
The guy can spend money on a buying a Russian Mig29 fighter plane.
I am sure he can throw some money to make someones life a misery because he can.
This is the well-known DeWitt clause, so named because Oracle crafted it to squelch database research being performed by Dr. David DeWitt. I believe these clauses should be clearly ruled as illegal, but to my knowledge they still persist. Details here: https://dwheeler.com/essays/dewitt-clause.html
I’ve never dealt with Oracle myself, yet even I’ve known about their reputation since before I joined the software industry.
I think the Streisand effect is not going to work in this case. The kind of people who decide to write Oracle multi-hundred-million dollar checks don't seem to care about this, because they have kept paying money for decades. So there's no reason for Oracle to care about it. The clause was added specifically at the direction of Larry Ellison. Larry Ellison is co-founder, executive chairman and chief technology officer (CTO) of Oracle, and the sixth richest person in the world... he has no reason to care what people think about these contracts, because no matter what he's still rich. The courts don't care about the Streisand effect either; they're used to people being unhappy about some of their rulings. And if there was going to a Streisand effect, you'd think it'd have already happened in the last 38 years.
Don't get me wrong, I loathe the DeWitt clause (as does DeWitt). Making the truth illegal, which is what this does, hurts all of society. But a Streisand effect will not get you there. What's needed is a court ruling or law that strikes such clauses down.
I'd much rather see a world where people can freely compare different products. I like Oracle's VirtualBox, for example; that thing can compete on its own merits. But that's my point; products should be able to compete on their own merits, instead of having legal clauses that prevent honest comparisons.
Larry would just rotate the banner, mission accomplished, no fine with a retraction.
Since competitors make bank selling Oracle solutions and can’t publish a bmark w/o his permission he doesn’t need to litigate. It’s his ocean.
also, this comparison would not register as a proper “benchmark” as it’s not even close to how you would perform a proper benchmark. it’s more of a data point.
on top of that there is the optics of suing a guy that wrote an email over some insane provision in your license. probably not worth it. and probably that provision is there to stop competitors from doing an apples to apples comparison and publishing the results that show how much oracle sucks.
as a closing thought: i’ve never heard about anyone starting a new project and even considering oracle as a db for it. it’s mostly locked in people that have to put up with this stuff. legacy code is a bee
I’m not sure how much it all cost to get started in the end, but it was a lot of cash before development even started. Aside from that, it was not a fun experience developing for it. I mean, for the most part a relation dB is a relational dB, but there was something about working with oracle that just felt broken compared to postgres.
I would prefer to not have to argue about that in court...
but at what point do you stand up and not let yourself be bullied? I think a half-decent lawyer can make a proper argument that this is not a benchmark.
I mean... does anyone here think this is in any way reasonable? Is this even legal?
There's no proof that figure wasn't Larry Ellison.
/s
At worst, you can refuse to do business with them and revoke any current contracts.
You'd have to sue under actual law, which would presumably be libel, which is (in)famously hard to prove in the US [1]. If he had a good faith belief that what he reported was true, that case goes nowhere. Indeed, in lieu of a signed and dated note declaring his knowledge that his benchmarks are (a) false and (b) shared in an attempt to harm Oracle, that case goes nowhere.
[1] https://en.m.wikipedia.org/wiki/United_States_defamation_law
But once you download a piece of software you're no longer dealing with the ToS but rather a license granted to you under copyright law. Those do have (arguably too many) teeth in the US.
I really don't like DeWitt clauses, I think they're horrific. But there's a reason people generally avoid fighting them in court - it's very expensive with an uncertain outcome.
Disclaimer: I'm not a lawyer.
https://www.nolo.com/legal-encyclopedia/personal-liability-p...
TL;DR: If a judge thinks your corp was just a protective shell, you can be held personally liable for its debts, and your assets can be seized.
Money is money everywhere. May be even more so in Russia.
I have no idea about China, though.
For more, see my essay, "The DeWitt clause’s censorship should be illegal" https://dwheeler.com/essays/dewitt-clause.html (I mentioned it in another thread, but you might not have seen it).
Don't think installation size or length of time taken to set up the program really qualify as a "program benchmark test", so he should be fine
I.e not extending his employers licence or making them pay even more.
Oracle loves to make examples and ain't pulling their punches
The most classic example I can think of was the McLibel case; one of the critical points in that being overturned was the gross disparity in legal resources of each side was considered a violation of the defendant's rights.
However, here is a similar comment (in French) from him in which he wrote that he isn't scared of replying to the patents lawyers himself. https://old.reddit.com/r/france/comments/736ghk/ama_je_suis_...
And here is the legal page of Videolan that some American lawyers may not appreciate. https://www.videolan.org/legal.html
The likeliest outcome is that nothing will happen. The second most likely outcome is that they will say "don't do that again". People in this thread have a lot of speculation as to how evil Oracle is, but I haven't really seen them go out of their way to ruin people's lives. They sued Google over the range check function because they wanted a percentage of Android, not because they wanted to make Larry Page's life miserable. Legal action costs money, a lot of money, and even companies we think of as evil don't go out of their way to expose themselves to lawsuits.
More scary to me than evil corporations are people that spread fear, uncertainty, and doubt to encourage others to self-censor where they are afraid to speak out themselves. Everyone knows about Oracle's benchmark clause. Everyone knows that you personally would never even think of violating it. The author of this post sees it differently, and on a forum called "Hacker News", we should celebrate the risk he's taking, not spread fear about what could happen in the worst case.
Don't generalise from your life; you only have to take care of yourself and Ayaya. A majority of people are deeply committed to a relationship/family/tribe, where losing all one's money definitely constitutes a crisis.
Here is my point -- the potential losses are bounded. They can't unteach you what you've learned in 30 years of work, so you can probably earn income even after losing the biggest lawsuit EvilCorp can muster. Or go work at Starbucks if you are somehow banned from using computers, which is not really something that can happen for violating a software EULA. Compare this to driving to work -- you could get in a car accident that leaves you with a permanent brain injury. You'd never work again. You'd never recognize your family again. It's a big downside! And yet we drive.
Furthermore, I would be a little surprised to be reading "Extreme Car News" and seeing the first comment say "wow, you shouldn't modify your car to have that kind of acceleration, you could die!" People are aware of the risk, as they are experts in the field, and we are here to learn what we can from their experience without taking the risk ourselves. It therefore surprises me that everyone on a forum called "Hacker News" is speculating about the worst case outcome for writing a single mailing list post. The discussion has devolved into a trainwreck of "look at what could happen to that guy, I'm glad that's not me," which I think is pretty nasty to the author of the mailing list post, and kind of against the hacker spirit. He took a risk. Let's learn what we can.
Are potential liabilities conjured up by corporate lawyers and awarded by courts limited by the amount of property or income you have right now, though?
Because if they aren't, you could end up owing and paying from your future income as well. Also, we have bounded time, and having your goals significantly postponed by financial setbacks isn't necessarily just a temporary inconvenience.
I'm not saying it's necessarily likely that one would end up paying anything, or a huge amount, or that people on HN (or elsewhere) wouldn't overestimate that probability or the potential damage, so of course this may be just a technicality.
(Also, the comparison to driving may not be very good, depending on where you live. While accidents obviously do happen, and the results can be devastating or fatal, in many developed countries the probability of an individual ending up in a major accident isn't really that great if one does not engage in specifically risky behaviour.)
If you are going around thinking "potential losses are bounded" you should read some of those stories and think about tail risk.
Corporations seem benign when you take for granted that their power isn't directed by anyone who has it in for you personally, and their employees are just going through the motions.
I actually do agree it's unlikely that Oracle will follow through with their implied threat, but let's not pretend that their threat is meaningless.
https://news.ycombinator.com/newsguidelines.html
Your comment would be fine without the first sentence.
If it's on Windows... it's easier to install a standalone DB, but way stranger to install a cluster. About 5 years ago I actually participated in a project where we had to install a cluster on Windows, and it took 5 days for 2 guys from Oracle (and they were not paid by the hour). They produced a document describing the steps (so the install could be reproduced) and it contained things like "and now add the Windows system registry key [...] and set it to [...]" (and I could not find any kind of documentation on what that key did on the whole Internet, but without it the install failed) or "now unzip the patch file, but do not follow the patch notes (to copy the a.dll from the root of the archive) but take the a.dll from the X subfolder" (for which there was no mention in the documentation).
Up until that point I thought the Linux cluster setup was hard, this changed the whole perspective :).
It's an interesting point of information, but a more relevant benchmark to support choice of technology would need to involve data access and manipulation using some kind of a workload that resembles an actual application.
At some point some big database vendors were showing full-page ads in prominent industry publications comparing database X to Y. This kind of clause in license may make publishing misleading performance figures a bit harder.
I think DB makers should take it as an opportunity to make inroads into developer communities, explaining how to configure and optimise, maybe even work together to create a standard test harness. Rather threatening to bankrupt anyone that talks about their database...
_if_
Of course, those aren't the only reasons, and probably not the the main reasons, why big orgs use bloated proprietary crapware.
Initial installation may not matter much but long maintenance windows directly lead to higher costs. If every patch requires a 60-90 minute downtime, you're going to pay for that in production deploy time.
And for service that's expected to work without interruptions, I think, there should be a way to switch to a secondary database, otherwise those promises are futile. And if there's a way to switch to a secondary database, long patch install time is not a big deal.
Because whether it's 1 minute or 60 minutes, it's interruption nonetheless.
Just look at Postgres[0] supported column data types and then look at Oracle[1]. Better data types means more tightly defined columns, which means fewer bugs/less defensive programming/reduced maintenance/reduced code complexity.
No doubt someone will be along shortly to tell me "you don't NEED it!" and then tell me how to hack constraints into making it act like something it is not, but I don't care. I have no interest in "forcing" Oracle to act like a modern database through repeatedly having to re-define 30+ year old common data types (e.g. Int32, Int64, Long, Bool, etc).
As a developer I /hate/ working with Oracle. It is just cludgy. I don't care how many times people point to vague indefinables for why it is "superior," it sucks to work with. Microsoft Sql Server is better, and Postgres/Sqlite are superb.
Just the fact Postgres has a date (with no-time) column means it outright wins. In Oracle, we stored them as <Date> 12:00 but that's a gotcha since it can get timezone adjusted in the pipeline (e.g. <Date> 12:00 becomes <Date> 08:00) and the result be subtly broken. Cannot time-zone adjust a real date type.
[0] https://www.postgresql.org/docs/9.5/datatype.html
[1] https://docs.oracle.com/cd/B28359_01/server.111/b28318/datat...
I think you misread the post you responded to.
It is discussing the benefit of Date Vs. DateTime data types. In Postgres, by design, a date has a 1 day resolution (i.e. no concept of hours/minutes, within that date). This is hugely useful for scenarios where you intentionally want and only want a 1 day resolution. It not being timezone adjustable is a feature, not a bug.
Storing a DateTime with 12:00 and then an offset of e.g. 0, is a needlessly complicated work-around when a data type that doesn't even have the concept of hours or timezones exists.
For example: If a user schedules an event to happen at 15:35 on July 29th 2021 IST, you cannot know with certainty what the equivalent UTC value is. You know what it would be assuming the relationship between IST and UTC stays the same between now and next year. If India suddenly decides to implement some sort of DST, or make any other changes to the definition to IST, the UTC value you stored is now wrong.
Timezones are political, but they're also how people organise their lives. The user's local timezone is context that you can't just discard.
It is not wrong. When timezones change, the database that contains that info is updated - but it still retains information about historical rules, precisely so that earlier dates can still be converted reliably.
On the other hand, if you use local times, then you are not able to distinguish between pre- and post-clock change, when the same time repeats twice.
But dates should never be stored with a timezone at all, except in extremely rare cases where a day for some reason specific to a timezone. But even then, it's much more likely that you are trying to specify a time range that happens to start and end on a certain day in a certain place.
Dates, almost by definition, are independent of timezone. January 1st, 2020 began at several different times in different timezones. It should be represented as a date stamp: 2020-01-01 without any timezone.
If you really are trying to represent the day that starts at 12:00 AM PST on January 1, 2020 and ends at 12:00 PM PST the same day, then you probably just want two timestamps representing those instants and not a date at all. But again, that would be quite rare. In most cases you would just want to store 2020-01-01.
For example, in a lot of countries, Labor Day is on May 1, Christmas on Dec 25. These do not happen at a certain time, and there is no timezone to be associated with these events.
If I'm requesting some user's birthday, I'm going to store it as a date. I don't have a time component. I don't know the time zone. In some cases, dates are just dates ...
But being able to freely/quicly stand up database servers and quickly create/drop databases makes development and testing much simpler and more reliable.
Given the question: "How do you know that deploying this thing will work?"
- When it's quick/legal to stand up fresh servers and create databases, the answer can be "I tested it, just now, and it works." - Otherwise you end up in "I read through it and it looks good" or perhaps "We tried most of it on the test instance last week before the other team started using it."
I much prefer the former.
For Oracle, a "database" is the a server instance; you create the database when you install the software (without creating a "database" you don't actually have anything running). For postgres, a database is just a level of data organization/segregation.
In an oracle instance you only have a single database. The equivalent of the postgres "database" would be "user/schema" in Oracle.
Oracle is a tried and tested safe bet when implementing corp wide, multi year projects. The HN crowd won't like it (and for good reason) but CTOs will always bet on name recognition when millions or billions are on the line.
But that's also because it's way harder to migrate a huge project/organization to a completely different DB - it's just cheaper and less risky to continue with the current one.
If creating a database takes 30 minutes, there is something extremely wrong either in the procedure the person used to do so, or in the Oracle software itself.
Creating pluggable databases (containers) is fast.
Obligatory: https://news.ycombinator.com/item?id=18442941
What I am interested in, is what are those features / problems. And if Postgre has a roadmap for those improvement.
I mean not just Oracle. Outside of HN the majority of dev and cooperation still swears by MySQL. I often wished HN instead of constantly hyping a technology, tell me up front what are the Cons. And hopefully everyone will make up their own mind whether the Pros and the Cons are worth trying it out.
And if so then with so many bugs at what point does certification become a negative signal?
Usually it's some three-way join with n:n:n relations which breaks Postgres' neck. I know exactly where the query should start from, statistics can't possibly know because they have no knowledge about the data distribution in adjacent tables.
I use CTE to "fix" this but the query would be faster without it.
Another issue is that plans can just fall over and you have absolutely no tools available to see what the old plan was, unless you ran explain before and saved the plan. You also have no way to force the old plan while you analyze the issue. This has caused more production outages than I'm willing to admit. With Oracle it would take me one minute to see what the issue is, and I could make the database use the old plan without changing a single line of code.
Even if updating analyses, creating indices, changing the query, etc. fails, you can always either use CTEs or temporary tables, or use a stored procedure that manually iterates over results to implement whatever strategy is desired.
It might be more time consuming than having query hints, although this is compensated by the fact that almost always queries just work after creating appropriate indices.
The queries in question can't be allowed to get any slower than they already are. They bottleneck certain critical uses.
And yes, this approach is fragile even in Postgres (version or data changes might affect the performance, or you might be stuck with a worse query when query planner becomes smarter), so I imagine query hints in Oracle have the same problem.
Disclosure: I implemented the Optimizer Query Hints feature at EnterpriseDB.
[1]: https://www.enterprisedb.com/edb-docs/d/edb-postgres-advance...
As for why they use it... as far as I know it‘s the old tale: historical reasons. Classical lock-in.
- planner hints
- better statistics (including ways to manually create statistics)
- no vacuum
- automatic planner adjustment when true cost was off
- better planning for prepared statements
- active-active clustering with RAC
- vendor support for running on SAN including snapshots
- usable query analysis tools provided by the vendor (pg_stat_statements alone doesn't cut it)
- datapump much faster than pg_dump
- better connection management
- out of the box backup tooling
edit: I haven't used Oracle in 4 years, all of that was available to me back then.
So, granted, other databases don't have Oracle's hacks to fix their broken stuff but I'm not sure why that is an argument FOR using Oracle rather than AGAINST. Hints are fragile hacks.
> automatic planner adjustment when true cost was off
More often than not, this "automatic adjustment" makes things worse.
> active-active clustering with RAC
But it's still shared storage, which doesn't really make it a true cluster in my opinion
> out of the box backup tooling
While this is true, there are several (free) backup tools that are easy to install and use and can rival rman's features.
I'm not sure why shared storage would be a problem, the world runs on SANs and making them redundant is pretty much a solved problem. For running a RAC cluster you are required to have at least two network paths for each cluster node. Furthermore cluster communication is separated from storage communication.
Comes as a no-cost option with the database, making Oracle the only complete, end-to-end, data management system I know of, where you can build and deploy rich web apps, "out-of-the-box", without installing or integrating anything else.
A friend of mine (experienced developer) built a web app with React, (CRUD and Dashboard) and it took him the better part of a day. Built the same thing with Apex in about 15 minutes.
That's a big reason we use it. Simply can't stand-up data centric, business focused web apps with as quickly with anything else.
YRMV
Did the Novell ownership make it similar/alternative to Oracle stuff? Or is it just that it was the first linux with a paid support option and those folks likely used it earlier because of this?
Asking for people that actually use openSUSE today, not other pundits with baseless hypothesis like myself :)
At the system level, even Oracle has to do some sort of message passing stuff to be able to distributed databases.
With the availability of streaming services, resilient distributed computation and data storage architectures, I hope companies like Oracle die a slow, but graceful death.
PostgreSQL and advanced database systems like FoundationDB, with help of stream / event processing systems, should be able to replace large Oracle clusters.
The problem of "lock-in" is a business problem and ought to be solved my the MBA's in my view.
Not that MSSQL isn't heading that way, and getting more weird and buggy all the time.
The Spilo docker container which packages PostgreSQL + Patroni was also always publicly available from the first day. I agree, the Spilo is a bit opinionated due to the way how it is used at Zalando.
These two projects have quite a long history and originally weren't even targeted to be deployed on K8s because back in 2015 K8s wasn't absolutely suited for running stateful workloads.
The most opinionated one is Zalando Postgres-Operator, and yes, first it was the internal tooling and was solving our specific problems. Now I would also argue that with such an amount of external contributors it already became a way more general solution.
After all, Patroni is so general, that we call it a template for PostgreSQL HA. You can take it and build something that you need/want without relying on Spilo and Zalando Postgres-Operator. Speaking of Patroni@K8s, there are already two very nice examples: Crunchy Data PostgreSQL Operator and StackGres are both relying on Patroni for running PostgreSQL HA on K8s.
As a side note, we've found that it takes quite a while for the initial pgBackRest job to run (like 8 minutes) which seems like a lot for an empty DB, but we aren't using SSDs
But this was a fairly small Patroni installation on a fairly small K8S cluster (6 nodes), so YMMV.
Is it pure C? Of course, building a DB is not something you worry too much everyday (unless you're developing it), but it seems an interesting fact.
It would be interesting to know how long does that system that takes 30s for the LK compiles PostgreSQL
-Sharding
-Java Pool
-Oracle Apex
-DB containers and pluggable databases
Many more that I am too lazy to list .
All of these come pre packaged with Oracle. If you are in an Organization that has 1000s of Oracle db’s per org, you quickly understand that license cost are a minute number but dba and developers are much more expensive .
But at the same time, it's a can be a huge speed bump in term of procurement. Waiting several weeks for accounting to accept the procurement of a license can really damage business or development speed.
It also adds significant admin load to track the license pool correctly and can represent a legal risk when inevitably, someone starts exceeding the terms of license (db size or db clones, or increase in hardware).
Is this how experienced DBAs commonly see the world?
We use Oracle's (newish) autonomous database offering, and haven't really experienced any bugs at all. No worries about backups, very little DBA time, and the on-demand licensing makes it quite economical. We just get on with it, and couldn't be happier.
Of course, YRMV.
One of my favorite features is the "time travel" query. If you enable this feature on one or more tables you can essentially say "give the results of this query as it would have been at time x". I don't know if anyone else provides that, but it's pretty great stuff.
I'm looking forward to seeing it in PostgreSQL.
[1]: https://www.pgcon.org/events/pgcon_2020/schedule/session/100...
I was working on some component and needed to add a new table to our database. I was fairly new to SQL at the time, so I wanted to do some experimentation and prototyping on my own, before submitting the schema changes to our DBA in order to get them into the shared dev database.
Oracle did have a free trial version you could download for dev purposes or learning or whatever, but like this mentions, it was slow and cumbersome to set up that I soon decided it would be faster to spin up a PostgresQL database, make any necessary changes to our schema and code to be compatible with Postgres, and do my prototyping there, then submit the schema modification request to our DBA. So that's what I did; it took a single evening to do all of that in Postgres, even for someone who was pretty much brand new to SQL.
After I submitted my schema chages for review, rather than emailing review comments back, my DBA made me come down for a meeting to explain the issues. Of course this was intimidating to me as a young itern; had I done something so wrong that it deserved a talking to?
After all that, it turns out the issue was that I had ordered a VARCHAR column before some other column of fixed width in the schema of the new table; and apparently, it's preferable to order all fixed width columns before all variable width columns in order to speed up the column accesses. I agreed with the DBA that I could change the order of the columns, though I did have to point out that this particular table was a table of worldwide regions like "North America", "South America", etc, and that there would never be more than 5-10 of these, so any optimization of this particular table was likely premature.
After all that experience; the complexity of just getting a dev environment up, the fact that production instances cost somewhere around ~$50,000 per CPU per year, the fact that we had a full time DBA who was spending a substantial fraction of her job letting interns know that they needed to apply some trivial optimization that you would expect such an expensive database to just do for you automatically, I resolved to never touch Oracle again if I could avoid it, and have had good luck in that I've never had to deal with Oracle in any jobs since.
Funny thing was that the project I was working on was named "ASAP" which officially had no expansion but unofficially stood for "Another Siebel Avoidance Project", because we were actually using our Oracle database as a place to dump information for which the primary store was Siebel, due to how much more of a pain it was to interact directly with Siebel so doing a periodic dump into Oracle and then building our API on top of Oracle was a better choice.
Something is oddly wrong in his tests if it took him 30 minutes to create an oracle database.
I bet its pretty close to 30m based on experience.
[1] https://www.postgresql.org/docs/current/sql-vacuum.html [2] https://reorg.github.io/pg_repack/
Lots of the classic hn "how can they be so stupid?" comments. Give the cto's more credit. Just because you write JavaScript and used mongodb once does not make you an expert on Oracle or running a very large business.
They now have a problem - and it would probably cost more than the yearly cost of Oracle to migrate.
2) Oracle Enterprise is free to use for dev/qa, but each prod instance costs money.
3) The contraint on publishing benchmark results is not what devs think. It's to prevent poorly conducted bm efforts, not really to hide anything. A vendor can't run around defending itself against non-DBAs doing benchmarks. Most of the links to results on HN admit, "We tuned our fave database, and used the defaults for the other database." Seriously.
Having said that, you can publish benchmark scripts, which is what MySQL did. That script moved the whole industry forward wrt reliability and performance, as MySQL was the only database that could pass initially. :)
Source: DBA.
"I don't like Oracle DB because:
- "Takes up more space
- "Is slower to start/stop/init
- "Is not free
- "Has bugs"
Umm... Sure, Oracle's slower to start/stop. Sure, it takes up more space. So what though?
And then, "it has a lot of bugs and that causes downtime." Would be great to list some examples. All software has bugs.
Why is this on the front page? Does it have any value what so ever other than "someone found a free alternative to Oracle DB"..?
It's likely upvoted because most of us in the industry have no love for Oracle and confirmation of that bias feels good.
Turnabout is fair play:
Why don't you give some examples of why a startup doing a greenfield project should use Oracle today?
That said, the original post is meaningless and yet on front page. That is what I'm writing against.
If all it takes for HNews to upvote an article is hatred of a company, that's a sad state to be in. Might as well get my free upvote with a simple isoraclestillshit.com website, eh?
Upvoting is both "I agree" and mark that in my voting history for if I ever want to see that page again.
Yes, this instance was not super deep but the fact is that it resonated with enough participants to get there. So the literal answer to your complaint is: it was a collective "because I felt like it".
Your complaint is not without some merit but also borders on "get off my lawn!". I've seen plenty of front page posts that I don't think are worthy of being there but, hey, different strokes for different folks.
- our engineers already know Oracle (this is absolutely reason #1). We don't need to get into religious wars about software, just to write good code quickly.
- Oracle is cheap enough for our needs. The price of an oracle RDS instance is immaterial in the grand scheme of things. We are saas so our customers will never be installing our software.
- noone ever got fired for buying Oracle. When our customers security teams grill us, running on Oracle and Java ticks one box on their spreadsheet. Same is true if we get acquired.
- Oracle is hugely scalable. Even if/when we get super big and successful, we won't need to change our database - there's always a bigger Oracle instance.
- Oracle is insanely reliable. In my career I've never seen data loss on Oracle that was not caused by human error. I totally trust that that will be the case going forward as well.
- as a company, oracle's not going away.
I'm sure some of these apply to postgres as well - but your question wasn't "which is better", which is a much harder question to answer.