MySQL, MariaDB, or Postgresql for TPA Pension consulting firm?

[u/amiliyon]

My company uses superbase, a software from 1980's for relational database...

Our computers are on windows 7, emulating windows xp. Safe to say our computers are dying.

The company is a TPA service for pension plans. We use superbase for client Tombstone information, work in progress, entering the clients assets, contributions, employee information etc. A lot of our work function is reliant on superbase.

I am very new to this world, don't have any experience in coding and don't know anything about any of these different programs. I just want to learn so we can convert and we don't lose our entire lifeline.

We are a team of 5 people. Small firm. We have our own servers, would not want to be on cloud, need everyone to be able to access the servers at the same time as we all have different clients and need to reach information. Not sure if its possible but would love for it to work on PC desktops and remotely on mac if possible, however, not a dealbreaker.

I have done some baseline research, this is what most redditors have suggested. Which would be the best for me to learn and hopefully be successful at transitioning over our information?

Any help in finding a direction to go to would be very helpful.

Thank you in advance.

If there is any more information needed that can help you in assisting me, please comment and i'll answer!

[u/alinroc]

I agree with everyone else, of the options presented go with Postgres.

I am very new to this world, don't have any experience in coding and don't know anything about any of these different programs

You're in over your head. Do not build this system yourself. Don't think you can't just vibe code your way through it. There's a mountain of regulations, reporting, security, and more that you need to navigate here.

[u/_DividesByZero_ → u/alinroc]

This is the correct answer OP.

[u/amiliyon → u/alinroc]

Didn’t think of those nuances tbh. You’re right. I will focus on building a mock up to maybe convince the boss man to cough up the money to do this

[u/lucasjkr]

If you don’t have experience coding, please don’t make your first project one that has anything to do with people’s finances or investments or retirements. That will just be a bombshell waiting to go off

[u/amiliyon → u/lucasjkr]

We don’t handle any money. We just do actuarial calculations based on EOY asset statements. Most of the real meat of the stuff we use is on another program

[u/reditandfirgetit]

I like postgres. It's got extensions for encryption that work well so you can secure the data well. Im sure mysql/mariadb have similar but I'm more familiar with postgresql

[u/Lordy927]

Postgres is the way to go

[u/Einar_Son_of_Bjorn]

Hello. Superbase is not just a database. It is the screens, workflows, and data together. Learning SQL alone will not replace what your team does every day.

Split it in two:

Data: an on-prem SQL database on your own server. MariaDB or Postgres will both handle 5 people just fine. The database is the easy part.

App: the forms you actually work in. That is the real project. For a non-coder team, that usually means Access on top of SQL, FileMaker, or a self-hosted no-code tool on your server - not a from-scratch rewrite.

Stay off a custom-coded rebuild. With five people and no developers, that is how the lifeline dies mid-migration.

To point you at one path, I need this:

1. How many Superbase tables/files, and roughly how much data?

2. Is the work mostly data entry + reports, or a lot of custom calculations and workflows?

3. Does the replacement have to stay 100% on your servers?

4. Who will maintain it after the move - one of you, or an outside person?

5. Will anyone work daily from a Mac, or is that optional?

Answer those five and the next step becomes obvious: list the must-have screens first, then pick the front end, then put SQL underneath.

[u/gkodinov]

You need professional services. Whichever way you go. The new database doesn't really matter: neither is easier than the others. And I do not believe AI will help you for free.
Hire a local kid to do the migration. That's how I myself started with databases a gazillion years ago.

[u/aipark2945]

I agree! IMHO, Postgres is the way to go. It is a very strong, reliable, feature rich DB!

[u/Hour-Measurement-835]

Did a few of these on ERP moves. Postgres replaces the tables under Superbase, it doesn't replace Superbase. Somebody still has to rebuild every form your five people type into.

[u/Gringobandito]

I feel for you buddy.

[u/amiliyon → u/Gringobandito]

It’s a pain.. can’t even open chrome properly anymore

[u/ArielCoding]

The hardest part is getting your old Superbase data out of it in a format the new system can use. Check if Superbase can export your data to a file like CSV or Excel. That will tell you a lot about how hard the migration is. Also ask whoever makes the other software you use for calculations if it already works well with one database, that might make the choice for you.

[u/Yellowcat123567]

From Superbase to Supabase. No joke!

[u/IncreaseNegative4614]

PostgreSQL would be my default, but the database engine is probably the smallest part of this migration. First inventory every form, calculation, report, permission, audit record, export, and undocumented workflow that currently depends on Superbase. The replacement application and data model need to preserve those behaviors.

Run both systems in parallel and reconcile several complete pension cases before retiring the legacy environment. We use SIGNLD internally to connect legacy fields, migration mappings, recalculated results, exceptions, approvals, and final records so discrepancies can be traced to the exact transformation that created them.

[u/Benny_Garc1a]

Heh, I did a similar task for an old family accounting office in Espania. I hope I haven't missed anything, the order is as follows:

Do it in this order. Do not skip steps.

1. Freeze what must survive
   Write a one-page list: clients, assets, contributions, employees, WIP, the 10 reports you cannot live without. If it is not on that page, it does not go into version 1.

2. Put MariaDB on your server, not in the cloud
   Install MariaDB Community on the machine you already own. Use the Windows MSI, set a root password, install it as a service. Create one database and one app user. Five people connecting at once is easy.

Start here:
https://mariadb.com/get-started-with-mariadb/
Windows install walkthrough:
https://mariadb.com/docs/server/mariadb-quickstart-guides/installing-mariadb-server-guide
MSI installer details:
https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/installing-mariadb/binary-packages/installing-mariadb-msi-packages-on-windows

1. Move the data before you rebuild the pretty screens
   Export Superbase to CSV. Create matching tables in MariaDB. Load the files. Check row counts. If the numbers do not match, stop.
   First SQL and tables:
   https://mariadb.com/docs/server/mariadb-quickstart-guides/basics-guide
   How to load CSV:
   https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile

2. Give the team a window into those tables
   Do not write an app from zero. Point Access, HeidiSQL (comes with the Windows installer), or DBeaver at MariaDB on your server. PCs work now. Mac remote access can come later over VPN.
   How to connect:
   https://mariadb.com/docs/server/mariadb-quickstart-guides/mariadb-connecting-guide

3. Learn only this much SQL, and turn backups on the same day
   SELECT, INSERT, UPDATE, and a daily dump. That is enough to not be helpless.
   Backups:
   https://mariadb.com/docs/server/mariadb-quickstart-guides
   (see “Making Backups with mariadb-dump”)
   Why MariaDB? Its perfect for fits the constraints: on-prem, multi-user, no cloud tax. The failure mode is not “picked the wrong database”. The failure mode is trying to rebuild Superbase as custom code with five people and no programmers.

Don’t worry about asking “dumb” questions in the thread. Paste where you got stuck and. I’ll check back and help if I can.