It has been known for DECADES that Oracle is outrageously expensive compared to the competition. But the unwillingness of larger companies to go with open-source databases which have no multi-billion dollar company behind them has kept Oracle in the saddle all these years.
I think that mission critical, legacy systems from a time before there was big OSS acceptance at the CTO level is the main reason. I’m not sure how many greenfield projects are using Oracle, but I’d expect that is rapidly decreasing over time. However, if you’ve had an Oracle db running for 20 years, and the cost of screwing up a migration starts at 9 figures, and runs into the 10 figures, then Oracle have you by the cost-benefit balls.
Oracle consultant here -> The Oracle world is shrinking admittedly and its shrinking from the smaller end up. I almost never get called by a company with less then 500 users or $100k a year of licence obligations.
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.
As a fellow Oracle consultant, I see the same. Most of the small clients only involve me in migration projects to other DBs now (postgres or mysql), but the ones with >$1M licenses continue to pay their support and migrate to 19c.
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.
I am a platform architect in a large company that has a few hundreds TB database servers that are not on open-source software; we do use Postgres in about the same number of instances, but not for the core databases. There are several reasons for that, from tooling (SSMS has no competition) or simplicity to manufacturer support; for example, using MS SQL setting up high availability or replication is a matter of a few clicks (or a page of code) with no extra add-ons, packages etc. and these features are perfectly integrated in the database engine, supported by the same company, come in the same installer. Even for smaller databases we prefer the free edition of MS SQL, for development, testing or validation we use the free developer edition, so the cost is not that bad, while the product is much more simple, coherent and better supported and this matters when you do the math. The day Postgress will have an integrated tool as good as SSMS, high availability and replication seamlessly integrated and the ease of use for the operations team to keep it in good shape without highly skilled DBA's, I am the first in line to evaluate and deploy it. Until then, it is not good enough, even for free.
You may not:
<<list of things you cannot do>>
- disclose results of any program benchmark tests without our prior consent.
I sadly suspect that Paul Förster might need a lawyer if anyone from Oracle finds out about that post. Which, given that this is trending on Hacker News, they easily might.
Oracle may very well want to litigate it. I doubt they care about the optics.
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 highly doubt Oracle cares about the Steisand effect. Oracle has long been lampooned for its lawyers, e.g., this old Bonkers World cartoon: https://bonkersworld.net/organizational-charts , and people have been complaining about the DeWitt clause since around 1982.
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 loved those full banner Exadata claims against competitors in your airport terminal. A week later, they’d be gone after HP/Dell/IBM/Cisco sent the lawyers to contest.
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.
people have known this things for quite a while (ie as as far as perf goes oracle is not worth it) and there is a reason why oracle includes that in the license.
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 was once subjected to the oracle dB for an ill fated social network project. They purchased 2 servers and oracle licences for 8 cores along with coldfusion licences and then it turned out that a special driver was required to allow them to talk to each other - I managed to find one from a company in germany that only cost a couple of grand. But hey, they were going to be big and only enterprise solutions were on the table - despite my suggestions.
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.
For anyone unaware of the details of this, here's the gist of it: if you run Oracle in a VM, you need to pay for Oracle licenses for every CPU of every host in the entire VM cluster, even if you know for sure it will never run on most of them.
Oracle has an entire VM suite, mostly incompatible with anything else and full of bugs, made with the only purpose of enforcing a core restriction so they won't bill you for the all cores on the real machines.
> 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.
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 can't argue with that. I suppose regardless of how ridiculous it is, Oracle has very deep pockets and is infamously litigious, and the US legal system doesn't help - given that, I doubt legality really matters...
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.
As far as I understand it you are correct about ToS not generally having much in the way of teeth in the US.
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.
A company absolutely can sue someone for violating the terms of service. For huge amounts of money, too, and it might be both you and your organization who have to pay. In the US it would probably be at least considered a contract violation & a copyright violation, not just libel. Contract law has a lot of teeth, and copyright violations have massive statutory damages. Oracle has a massive legal department; they can probably find a thousand other laws it potentially violates without blinking an eye.
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.
It's not about making it reasonable, it's an open threat to punish anyone who does decide to benchmark Oracle. Nobody's going to win the case, but whoever violates the term will surely wind up bankrupt defending themselves.
Better yet, publish as a Russian or Chinese resident. Disclose results to a (preferably not Oracle-using) tech newspaper on the condition of anonymity.
Last time I checked, Oracle had some kind of branch in Russia. Not sure whether that clause is enforceable within Russia laws, but they could just bribe police, so they would make one's life quite miserable.
Money is money everywhere. May be even more so in Russia.
publish over tor with steps to replicate. lack of authority shouldn't be a problem because anyone can replicate it. reputable people might even be able to say they endorse the findings without running afoul of the EULA, considering they're just saying yes/no, not disclosing the results of the benchmark.
I've heard of others prohibiting benchmarks before, which I can at least begin to comprehend (fair benchmarks are hard) even if I disagree. But prohibiting discussing things a product can't do is a new one on me.
I think this clause is not reasonable and should not be legal. However, these clauses (they're called "DeWitt clauses") have been around for almost 40 years and they have not gone away.
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).
Why not? Installation time and disk size are two values that may be important for some customers, and measuring those might therefore be considered benchmarks.
Chances are, he lives in a country where essentially saying "by purchasing our product you agree not to tell anyone how bad it is" is unenforceable. That might even include US.
The fact that something is unenforceable is a poor way of stopping rich lawyer-based companies, such as Oracle, from attempting to enforce it nonetheless.
Not all countries allow the "sue to bankruptcy" litigation model. I'd truly love to see this unfold in Germany, for example. They typically award costs to the winner too.
While you're likely correct that this wouldn't work in Germany as in a situation like this Oracle would've to pay their layers, the defendants lawyer as well as the courts costs if they repeal too often... There are other avenues for them to ruin his live, which I can imagine them taking.
I.e not extending his employers licence or making them pay even more.
Oracle loves to make examples and ain't pulling their punches
I mean it probably would be a protracted battle, but one that a person would likely be able to win in the EU.
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.
DeWitt clauses (the name for these clauses) have been around since the early 1980s, and have not been struck down yet. I would love to see them disappear, though. For more, see my essay here: https://dwheeler.com/essays/dewitt-clause.html
SQL Server has the same thing if I’m not mistaken. There’s a big reddit benchmark post that goes out of its way not to say SQL Server in the benchmark just for that reason.
People are scared of corporations, but they don't really have much ability to damage you. They can't cause physical harm to your body. They can't take away your loved ones. All they can do is take some money. You started life with $0, so you can probably make it all back. It would be inconvenient, but not an existential crisis.
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.
> It would be inconvenient, but not an existential crisis.
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.
> Here is my point -- the potential losses are bounded.
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.)
Every now and then you read a news story about something that you might expect would be a civil litigation matter becoming a criminal case.
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.
Your first paragraph is totally ridiculous. Maybe you started with $0, but maybe that was 30 years ago and losing all your savings from then till now, including your home, is more than an inconvenience. If you have dependants then that loss could directly impact their lives and especially their education – what if some of that money had been for a college fund? In the US especially, and also to some extent in Europe, having less money affects what medical care you can afford, so it actually can cause physical harm. At the extreme end of things admittedly, these changes could put strain on relationships which could even mean you really do lose loved ones.
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.
Yes, it can take that long. They actually forgot to add some tasks, like prerequisite changes in the OS settings and packages (for Linux). And a cluster setup can take way longer (as you need networking setup, DNS setup, OS users, shared storage and so on). And after that you have to setup a way for it to automatically start (if it's not a cluster but a standalone db). But they also cheated a bit, as you can install a DB without containers and it takes less time and less disk space.
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 :).
In most scenarios involving databases you would probably be much more interested in run-time performance and scalability than in setup time.
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.
Maybe one justified reason is that proper benchmarking can be hard. Especially running fair benchmarks between competing complex products.
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 do agree that benchmarking is hard, especially for databases that have so many knobs and buttons to tweak things to suit particular workloads.
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...
I'm a big fan of Postgres, and it's got plenty going for it. That's not to say Oracle isn't a good database in its own right. The knocks against Oracle tend to be lock-in, complexity, price, but rather than go in a checklist comparison I'd rather say what's unique about Postgres:
- 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.
The original comment was about how few packages and how little space Postgres takes. PostGIS is good but it pulls in a lot of extra packages.
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.
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 think the addition of LLVM for JIT execution of plans added a lot to the Postgres install baseline (at least in distribution packages, you can compile a much leaner postgres yourself).
Due to the way that the LLVM dependency in postgres works, it could be packaged separately from the base postgres server package. The LLVM interfacing code is runtime loaded, and there's no error if "llvmjit.so" is not on the system, even when the server was built with LLVM support. It's basically a packager's choice whether to do so, or not.
"Based on its license it's very hard for any one company or individual to 'own' Postgres"
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.
Worked on a large application for the Dutch government with Oracle as database using spatial. Oracle is the only database that implemented spatial wrong (in my opinion). Oracle is the only one that implemented spacial functions to have a parameter for the accuracy. So basically you spacial function could calculate things wrong depending on that parameter. We had issues in the calculations when we where subtracting land to see what parts we needed to buy from land owners for laying new roads. We could not fix this. Oracle didn't help. They payed millions for licenses but they did not offer enough support in my opinion. I did some of the calculations in postgres with the spacial extension and most of them where way faster (10 times was not uncommon). Postgres also did not fuck up the calculations like oracle did. The project actually had a huge amount of psql code and we could not switch to postgres...
Oh! This looks like a very interesting project. When I finished reading the headline description I was immediately turned off by the mention of Zookeeper. But it then goes on to say "OR etcd OR consul". If this project does what it claims, that's pretty awesome. I'm definitely going to be looking at this a lot more.
We recently rolled out Patroni on k8s and it definitely does not “just work”. I suppose once you get it up and running, there’s some truth to that, but it’s one of the most hostile pieces of software I’ve come across. This isn’t a complaint, after all, Zalando don’t owe me anything. But the documentation, the project structure, the contributors...it all reveals very clearly that this is really just some internal tooling that they happen to make public, as opposed to a first-class OSS project. Unfortunately it’s also the best Postgres HA system out there, but it’s truly a massive PITA to get setup and it’s extremely opinionated about things that it doesn’t need to be.
After spending quite a bit of time with the operator early on, along with the KubeDB operator (super easy to use, but definitely not production ready) we settled on some patroni helm charts.
Patroni was openly developed from day 0. The repo was created in early July 2015, but before that it was living as the fork of Compose Governor.
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.
Hi Cyber - yes I know it has a very active community, and you and I have interacted on github before. But I find this response very similar to github: it’s a template, so build whatever you like with it. That’s not what most people want, and that kind of a reply reinforces my comment. I don’t use React because I want a template for for building a reactive application. I use it because it does all the things I don’t want to have to be concerned with. Like I said, I don’t think any project needs defense. I thank you all for the work you’ve done. But it is not the easiest bit of kit nor the most helpful/inclusive community.
I recently have been working on setting up a HA Postgres Cluster on K8's... its for a pretty small DB use case and not knowing much about the world of Postgres and Databases I ended up using the Crunchy Postgres Operator which amazingly did all of the work for me... (I honestly don't know much about Patroni other then it manages the switchover to replicas during a failure)... anyway I'd recommend the Crunchy Operator...
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
Perhaps our setup was different than the sibling comment describing a bad experience, but I found, compared to other complex K8S charts, that patroni was exceptionally reliable, medium easy to setup, and I would generally be grateful if everything worked as well as Patroni did.
But this was a fairly small Patroni installation on a fairly small K8S cluster (6 nodes), so YMMV.
- 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.
Funny story: I worked at a place which spent millions annually with Oracle. They had a couple hours downtime every day because they couldn’t afford the online backup product.
This was an Ivy League university with an endowment in the tens of billions.
That may be the case now but it was either different back then or neither their Oracle-trained DBAs nor their Oracle consultants was aware of it.
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.
MSSQL can roll back DDL. But the DDL changes are not fully transactional, as other trans sacri one can see new columns and tables before the DDL transacrion commits.
Postgres gets it right. DDL is contained in the transacrion until commit.
SQL Server partially supports it - indexes for example are not versioned which causes snapshot transactions to fail if someone rebuilds an index - even if it’s not in scope of the snapshot.
That doesn't sound right by my experience, Could you give a link please? I'm concerned I've not heard of this. Probably because it's MVCC/snapshot isolation which I'm not familiar with.
We have a database server at work that costs us about $10k a year. It’s bare metal so that gets a nice spec. We’re probably a little over provisioned, but not crazy so.
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.
> No license fees is huge. My company saves tens of thousands on license fees when we can't really afford it.
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.
Having DDL is nice until you are trying to add indexes to a production system and can’t have it locking the entire table. Then you need to add the index concurrently and Postgres does not support concurrent index creation inside of a DDL transaction.
- 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" :-)
I guess the negative reactions are because you're making statements without anything to back them up.
> Why are you worried about license fees as a developer?
Lots of developers are involved to some extent in financial decisions. And in any case, I'd be worried about losing my job because Oracle had bankrupted my employer..
> Seriously speaking, start with Oracle SE2. It is so cheap
Postgres is free, and open source too.
> Oracle Public Cloud gives you database extremely fast
It's extremely unlikely that devs will want to host a database in Oracle's cloud, and everything else in AWS/Azure/GCP.
> and you will never have issues with license audit
The very fact you felt the need to throw that in is exactly why people hate Oracle so much - they are absolutely infamous for screwing customers out of every cent.
> The name of "Rollback of DDLs" is "no developer access to production" and "UAT"
As others have said, it's useful for testing changes in pre-prod environments - so you can make sure stuff works before it gets to prod.
> Are you a huge fan of Vacuuming, XID Freezing, WAL optimisations etc. etc.?
This makes no sense; vacuum is automatic, and why would you not want knobs to tweak settings to your workload? Oracle has plenty, so I don't get your beef here.
> The MVCC in Postgress, in my view (!) is joke from academia, where they had not a single DBA
I've never heard a single sole claim such a thing - do you have any sources?
Aside of auto vacuuming, there is also VACUUM FULL [1] which does an exclusive lock on the table.
If you look for an alternative option for reorganizing tables in online mode, try the pg_repack extension [2].
Vacuum is online, but with a caveat iirc, it locks the table with a lock that does not block inserts/updates/reads. But if your application use exclusive locks, things can get blocked.
That's not a very useful comparison. Databases are made to execute queries, not to install them. The only useful metric is performance and features (and price, of course). Sure, Oracle is bloated and pain to manage, but if it works faster, provides unique features and costs less in the end, people will use it.
> That's not a very useful comparison. Databases are made to execute queries, not to install them. The only useful metric is performance and features (and price, of course). Sure, Oracle is bloated and pain to manage, but if it works faster, provides unique features and costs less in the end, people will use it.
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.
That depends on a service. For example I'm working on a service which is used by people at working hours (something like 8AM - 19PM, Mon-Fri). I can do anything outside of that window (well, +-30 minutes just to be sure) and nobody's going to pay for it, most likely nobody would even notice.
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.
You should store dates with timezone or you can't make calculations like how old is this post. You could base it off system time, but then the calculation have to take into account summer/winter time.
> You should store dates with timezone or you can't make calculations like how old is this post.
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.
> 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.
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.
You're not converting a historic date though, you're converting a future date. And that's an inherently uncertain process. It is literally impossible to know what UTC time 2021-07-29T15:35:00 IST refers to until it happens. The Indian government is free to redefine IST as they wish, and could choose to do that at 15:34:59.
Some parts of Brasil decided to not observe daylight savings this year. I had to file a bug with Chrome which was converting dates in JS off by one hour for some Brazilian cities. Firefox got it right. If a couple of years ago you had stored my future appointment in your db using UTC, your db would now have the wrong time for my Brasil appointment.
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.
Some times it does not make sense to associate a time component to a date, just because it happens on a day, not at a certain time.
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 ...
For those born around new year the hour is important as it will decide what year they are born. It will also be important for birthdays, You don't want to send happy birthday on the wrong day - which can be different depending on what timezone they are in.
> Databases are made to execute queries, not to install them.
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."
Actually, the whole "create database" is misleading when comparing the two.
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.
Not at all. Because Oracle does not have multiple databases per instance does not equal a PostgreSQL database to an user in Oracle. On the contrary, it means PostgreSQL is way more flexible, because there we have and databases, and users and schemas as ISO meant it.
With the amount of hype and mind share micro-services attract, I hope the era of large database clusters like Oracle comes to an end.
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.
There will always be a lot of use for large databases. PostgreSQL does provide some under-the-hood features for doing distributed db's (such as the PREPARE TRANSACTION extension) but the actual implementation work is left to the user - there's no such thing as a "one size fits all" solution in this domain.
Wouldn't it be great if there was a large system for integrating all those data based microservices, taking care of data coherence, type verification, and schema migration, all of that behind a standardized interface that every language supports?
Honest question, what is that with former Oracle clients and SUSE LInux?
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 :)
SUSE is reasonably popular (it's to Europe as Red Hat is to the USA, if I understand right), and SLES is (like openSUSE) RPM-compatible, making it reasonably friendly to large enterprise software packages (like, say, Oracle DB). I'd expect most people using Oracle DB to be doing so on either SLES or RHEL (or some derivative of the latter, like Oracle Linux).
Depends a lot on what machine you are using and how parallelized the compile script is. Modern CPUs (threadripper 39x0Xs) can compile the Linux kernel in under 30s. With that in mind, does is it really surprising that Postgres can take 3.30m?
Query hints are one reason. I'm not a fan of Oracle as a company, but for certain usage patterns you need query hints and Postgres doesn't support them.
PostgreSQL provides a variety of options for tuning both the query planner's strategy and the per-table statistical analyses that are used as input to the query planner itself. These tuning methods are actually far more robust than the query hints that are commonly used in other databases, including Oracle.
I'm not a DB expert by any means, but the DB experts at my job are pretty insistent that (given the way we deploy our software) it's not practical to do in Postgres what we can do with Oracle query hints.
You usually have one query that you need to optimize but hundreds more that query the same data, therefore messing with the statistics of a table is hardly ever optimal.
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.
I don't think it's likely that you ever really need query hints.
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.
Do query hints lock in the implementation though? I imagine that DB upgrades could have different performance characteristics both with and without hints.
I believe the GP post was referring to restructuring your query so you make Postgres hit better indices (eg. when you know the distribution of data but can't easily apply a partial index). A common way to do that in Postgres is to use subselects for a criteria, and the join in the outer query. Coming up with such queries is "more time consuming".
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.
Several of these are "features" exist to fix broken parts of Oracle (like query/planner hints, planner adjustment, etc). Officially (per Oracle) the planner should be good enough so you never need to use a hint, but realistically all of these are "features" because the built-in systems aren't good.
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.
So what do you do when you encounter bug in Postgres planner? File a bug and wait for months or years until fix is released? Hack postgres source and fork it? Using hints sounds like a more sane solution. Nobody's perfect. Being able to work around is better than not being able to.
What DB has a better active-active HA cluster option than RAC? I love me some Postgres and MariaDB but I've never seen anything come close to RAC for making high volume queries against active-active just work.
A query hint is a clause you put into the query to make the planner execute the query in a certain way. Planner hint might not be the right term, Oracle has tools to show you different execution plans and to force a plan without touching the query on the application side.
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.
I seriously doubt that the author has 20 years of Oracle DBA experience yet not know why Oracle takes up more disk space that Postgres.
There are so many features in Oracle for which there is no equivalent in Postgres.
-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 .
License cost tend to be negligeable compared to the cost of devs, dbas,sysadmins, etc, that's true.
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).
And vendor lock-in with them. With PostgreSQL, one gets freedom to add your own, also free components, and even to substitute another ISO-compliant DBMS.
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.
Well, if the database has the number of tables, triggers, stored procedures, etc that SAP or Oracle’s ERP has then this seems less unreasonable. We’re talking thousands
In the Oracle world, creating a DB is not something you do often. In most cases you only have a database on the whole server/cluster and all the applications will use that database instance, being isolated at user/schema level. So that 30 minutes time is not that important actually.
Creating pluggable databases (containers) is fast.
I'm not as familiar with Oracle, but surely it is providing significant benefits or large organizations would be dumping it and running to more reliable alternatives. These time estimates are also not very pertinent to the actual running of a large database. Nor do they speak to the various technical problems one has when running a big db that is mission critical.
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.
It's still used in a lot of places because either some bought in ERP system requires it, or because internal software was developed on it WAY back when, when either Postgres didn't exist, or didn't have as many features and no companies providing paid support.
They now have a problem - and it would probably cost more than the yearly cost of Oracle to migrate.
I am sure there are many areas that Oracle is still technically better than Postgre.
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.
One reason that I've heard is cluster, Oracle supports clustering while Postgres only provides half-baked solutions. But that was years ago, so I'd like for correction.
I've used plenty of Oracle; it's a poor choice (probably the worst) for organisations of any size. People buy Oracle in large corporations because that's what their leaders and their team know, and it helps them stay relevant in the company. Especially in places where daily work is more about engaging in office politics than dealing with technology.
It's often higher performance and with better HA solutions than any other options. I have a lot of dislike for the company, but it's silly to say it's a poor choice for any organization size..
I am not in favor of Oracle. I don't care about Oracle.
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?
It's a combination of hate of Oracle and love of Postgres; there were nuggets that validated those feelings.
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.
Data point of 1 - we use Oracle in our greenfield platform (in 2018). My reasoning:
- 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.
I can't say that I saw data loss caused by Oracle. But I saw plenty of cases where Oracle required manual intervention to be able to start up after something gone wrong. I never understood why Oracle does not self heal, because those interventions were obvious. I don't have much production experience with other databases, so I can't comment about that, but it was sometimes as simple as power loss which caused Oracle failing to start until you run some mumbo jumbo from sysdba.
My company uses it all the time. It's an absolutely rock-solid database and I've never had any issues with it. They just released their new containerized version a few months back and have recently simplified their licensing rather significantly.
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.
Bitemporalism a la SQL:2011 has been partly or wholly implemented by several RDBMSes at this point. Off the top of my head SQL Server, Oracle and MariaDB have it as well as DB2.
I'm familiar with these and they are useful, but I would greatly prefer mainline support using the SQL standard. A mainline implementation is far more likely to lead to optimisations being made to the query planner, indices, disk formats etc.
You may be pleased to know that someone is actively working on this. There was a presentation [1] by the author Paul A. Jungwirth at this year's PGCon last week.
I had a similar experience to this at an early programming internship while I was in college 20 years ago.
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.
> What I especially hate about Oracle (despite the license costs, of course) is that it has so many bugs, bugs and even more bugs and one keeps on searching for patches all day, generating lot of downtime. Applying a PSU or RU is mostly not enough.
I bookmarked this tweet from 2012 - "I wish I had enough money to run Oracle instead of Postgres." "Why do you want to do that?" "I don't, I just wish I had enough money to."
237 comments
[ 1.7 ms ] story [ 292 ms ] threadOracle 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.
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.
I sadly suspect that Paul Förster might need a lawyer if anyone from Oracle finds out about that post. Which, given that this is trending on Hacker News, they easily might.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
[0] http://en.wikipedia.org/wiki/Streisand_effect
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...
- 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.
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.
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.
- 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.
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 :-)
Ok - considering the audience, obviously the best database is JS based KV Store with AI optimisation, controlled by K8s!
You know, "schema on write", "schema as a code", APIs etc.
> Why are you worried about license fees as a developer?
Lots of developers are involved to some extent in financial decisions. And in any case, I'd be worried about losing my job because Oracle had bankrupted my employer..
> Seriously speaking, start with Oracle SE2. It is so cheap
Postgres is free, and open source too.
> Oracle Public Cloud gives you database extremely fast
It's extremely unlikely that devs will want to host a database in Oracle's cloud, and everything else in AWS/Azure/GCP.
> and you will never have issues with license audit
The very fact you felt the need to throw that in is exactly why people hate Oracle so much - they are absolutely infamous for screwing customers out of every cent.
> The name of "Rollback of DDLs" is "no developer access to production" and "UAT"
As others have said, it's useful for testing changes in pre-prod environments - so you can make sure stuff works before it gets to prod.
> Are you a huge fan of Vacuuming, XID Freezing, WAL optimisations etc. etc.?
This makes no sense; vacuum is automatic, and why would you not want knobs to tweak settings to your workload? Oracle has plenty, so I don't get your beef here.
> The MVCC in Postgress, in my view (!) is joke from academia, where they had not a single DBA
I've never heard a single sole claim such a thing - do you have any sources?
[1] https://www.postgresql.org/docs/current/sql-vacuum.html [2] https://reorg.github.io/pg_repack/
_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.
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.
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.
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 :)
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
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
-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).
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.
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.
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 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...
"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.
Is this how experienced DBAs commonly see the world?
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.
Obligatory: https://news.ycombinator.com/item?id=18442941