There are still lot's of folks using Access. For those of us in the Linux space, we can use Libreoffice Base and script it with python. I once built for a local business that needed to join the computer age using this. Then about a year+ the owner's relative came to the business and decided that it was too old school and to get it redone as a web app. Needless to say, the owner is not too happy with it, took too long, cost too much both to develop and run and has more errors. He lamented to me about it when I was in town... The issue is the world has moved on from local/native apps.

Claris Works on Macs in the 1990s is the best database product I’ve ever used. It was amazingly user friendly. I used it to make form letters & reports. Claris Works prioritized the application layer of the database and hid a lot of the complexity at the data layer.

DB Browser for SQLite is the coolest database product I’ve used recently. Similar to Mito, DB Browser generates SQL into a log as operations are performed in the GUI. Kind of a fun way to learn some basic SQL. I need to find a good GUI authoring layer for SQLite…

> I need to find a good GUI authoring layer for SQLite

MS Access with an ODBC connector.

Filemaker Pro occupied that space a while ago as the MS Access for Mac.

I'm structuring my UI for Adama (https://www.adama-platform.com/) around the baby of Access and Excel, and the engine is available in early access now. I love Excel and Access, and I plan a future pivot into small business space.

Microsoft Access is, of course, still around. It would be great if there were a solid way to develop a database, forms, and reports in Access and then deploy it to the web.

If you've ever had to work with someone else's Access database, it is unusual to see a reasonably normalized relational database. Most people are much more comfortable with the single flat file of Sharepoint lists.

For stuff at the scale of a small Access database, does the normalization (or lack of) end up being a big deal?

I get that there are real advantages, I'm just wondering out loud whether they are universally applicable/important to small scale databases.

Speaking as someone with direct experience maintaining Access databases that should have been SQL Server from inception, yes it absolutely does. If you need to force feed 10+GB through Access artificial 2GB constraint and your programming language (VBA) is both single threaded and interpreted, if you aren't clever then you will run into performance problems, just as you would if you were doing something similar in Javascript or Python + SQLite.

I'm imagining a few hundred thousand small records when I say small, not 10 GB.

Probably matters as it relates to data quality mostly

That's a good question. For an honest and complete answer, I'd have to remember the messes I've seen and it's been a couple decades now, so I don't. But simply, everything in setting up forms and reports is more convenient if you have real relations as opposed to a bunch of columns like "supplier1, supplier2, supplier3...".

This is what we’re building with https://www.glideapps.com

Does it exist a good Microsoft Access replacement?

Appsmith was recommended last year.

https://github.com/appsmithorg/appsmith

https://news.ycombinator.com/item?id=26657803#26658546 Ask HN: Best low-/no-code solution for simple web-based database frontends

How was it recommended?

By being voted to the top of the discussion??

I must be missing something obvious - I don't understand your question.

For read-only workflows Power Query is the killer feature of the past decade.

For writes, there's Airtable, Google Forms, PowerApps etc.

My anecdotal experience says Power Query.

I did wonders with FileMaker Pro for years and my understanding is that it’s still around as well.

sounds like you are describing grist

https://www.getgrist.com