Costs?
In large companies and organizations, people like to know what to expect in terms of IT costs. So because Oracle costs fluctuate every year, this is particularly difficult. License costs can quickly run into tons, if not millions of euros per year – if you have many databases.
So what if you could save these costs? Do it right away, any right-thinking person would say. And this is happening more and more, many companies are now familiar with the wonderful open source alternative PostgreSQL.
Rightly so, in my opinion, because thanks to its loyal and brilliant community, this database really is a full-fledged alternative to Oracle.With PostgreSQL, you can estimate much more accurately what the annual costs will be. Of course hardware is needed and you have DBA work, but you incur those costs even if you use Oracle.
And between Oracle and PostgreSQL, those hardware costs hardly differ. Converting an Oracle database to a PostgreSQL environment does take many hours, but you’ll recoup those costs quickly. How quickly depends on a number of factors, such as the number of databases and the amount of work it takes to translate Oracle-specific syntax to the SQL standard. After all, PostgreSQL conforms to standard SQL “rules,” as do MySQL and MariaDB, among others. So you avoid any kind of “vendor lock-in.
If there are thousands of databases, spread across different servers in various cities, then we can quickly reduce the cost. Migrating so many databases is a big job, but by bundling as many databases as possible into the smallest possible hardware environment, the costs are already reduced.
It is then a matter of really removing Oracle completely from a location, because if it is left on a server somewhere, you are paying (so to speak) for all the hardware that is there. Because you could be using Oracle on that. Because we live in a 24/7 society, we try to make migrations as fast and as smooth as possible.
Ora2pg
We have standardized the migration process as much as possible. We use the open-source program ora2pg for this purpose. This allows both the data structure and the data itself to be transferred and translated to PostgreSQL structure. Thanks to nice tweaks like incremental migrations for static data, you can prepare the migration largely in advance. For example, you can migrate very static databases ahead of time so that you can minimize downtime during the “real” migration.
Because a large company (for example, a multinational in the automotive industry we work for) has many thousands of databases, it is practically unfeasible to provide customization for each database. The process is 99% standardized and automated. In doing so, we set very clear frameworks.
For example, no more changes may be made to the data structure during the migration. And we state very clearly in advance what we do and don’t do. We are an additional tool for the application teams to migrate their data consistently.
Curious?
Would you like to know more about Optimadata? Feel free to contact us.