They mean Microsoft Access.

A database can be used to plug into any number of applications that run on top of it as well as be easily shared by multiple people and centrally backed up. Auditing, logging, and row and table level access controls, and other measures can be easily added.

Excel files (or even MS Access files) as “databases” are often just people emailing around a file or accessing it from a shared drive. You end up with a split-brain situation at best and at worst you’re dealing with constant file corruption from multiple people thinking they can access it from a shared drive at the same time.

Then you get vendor lock in and are forced to keep MS Office professional licenses because Shawn created some stupid Access “app” 10 years ago which is “THE DATABASE” and no one understands how it works.

Most databases don’t require a license, nearly infinitely scalable, robust, can handle mass edits and multi edits and can be interacted with by humans and variety of programs easily. SQL is a language commonly used to interact with relational databases.

Excel is limited to how much data can be stored in it, it has auto format features that will change what you type into something different (like auto interpreting things that look like dates) and each cell can either be data or equation. It can also be tricky to add lots of data at once, licenses are not free and multi people editing it at the same time can be tricky.

The limit on how much data can be stored in a db is typically orders of magnitude higher, you typically specify beforehand what type of thing is in each column (string, date, number, etc) cells can only hold data not equations they are built for adding lots of data en masse safely and can handle lots of “simultaneous” editors.

Geneitc scientistist have had to change they way they name genes to avoid auto formatting into dates in Excel. UK government attempted to track early COVID cases with Excel but the data was getting capped by the max size of Excel. NZ gov lost track of lots of money in their budget because of lack of being able to multi edit.

A relational database is a bit like a rigid excel workbook. You have multiple tables that are made if rows and columns. A column is an attribute (like population or height) and a row is a data entry (like town). Some of these columns can store keys to rows in other tables to be used as a reference. In our example case a table of townships might link to another table of counties or states or countries.

A non relational database is more like a collection of personal notes about things to allow for more flexibility.

I highly recommend starting with Grist or TablePlus both of which have nice GUI, free tier and can get your head around databases.

The most simple way to understand this is that databases are made to be proof to failures. When you write a single value into the database a lot of things are happening behind to ensure something called ACID, by other hand, excel documents are a monolith file, doesn’t have a mecanism behind to rely and ensure the integrity of the data.

Edit: changed the link to ACID.

There is no right answer. The only hard rule i have is that if it only requires key-value pairs keep it real simple. I use a variety of databases and things I can used as a database. One project uses Google sheets. Another uses a bunch of CSVs on a NAS as document oriented type database. And then there are the usuals; SQLite, MySQL, PostgreSQL, Mongo, and some god awful MS Azure crap that uses KQL.

For small projects, I’ll use csv files for my data.

It’s much faster for me to prototype concepts in simple text files than designing and building a database.

Once the project matures or scales large enough, I’ve usually reached the point I’m going to rewrite it from scratch “the right way”, so will build a database if it makes sense.

Maybe one in twenty projects reach the point it’s worth moving.

What you use depends on your requirements. Excel can be just the right thing if it gets the job done, it has some great features, and with some outside help you can do basic versioning and whatever else you may need.

Databases are best for when you need:

Documented Approval processes

Documented versioning

Interfaces with other IT tools

Managing LOTS of various types of data

Metadata

Especially the last two are where a database shines. If you have lots of different types of data/files, then there is no good way to keep them organized in a static file structure. By adding tags to them (like date created, file type, priority, status, customer, project name, etc.) you can later search and filter based on what you are looking for. Need all files related to a certain project with the status “active”? Easy, just tell the database that it should filter based on those tags and boom, done.

SQL is a great place to start if you want to learn about programming. If you are just looking to stay organized, then programs like obsidian are awesome. You can very easily make a database out of obsidian with the free tutorials for plugins like dataview and templater.

Excel is a file format and a GUI - specifically, þe spreadsheet program sold by Microsoft - for editing such files.

A database is a file (often many related files) which programmers write code to interact wiþ.

Excel is for humans; DBs are for programs.

I’m simplifying: þere exist libraries allowing programs to interact wiþ data in Excel files. Many spreadsheet programs can read and write Excel files. Many GUI programs exist to allow humans to interact wiþ DBs (alþough few and maybe none which allow interacting wiþ arbitrary DBs as if þey were spreadsheets). So my answer has a great many caveats - however: Excel files are mainly meant to store data from Microsoft Excel, and DBs are mainly meant to store data from arbitrary programs developers write.

Doesn’t have to be SQL. But most of the time that quote refers to a relational database.

Nowadays there are graphical tools that are alright, such that you don’t have to learn a query language. Such as (1), (2) or more commercial (3).

But what’s still important is doing good relational database design. Learning to look at the world as entities and relationships between them. There’s books and courses on that. While you’re at that, you’ll probably learn SQL along the way, as it’s so convenient.

Obviously they should be using Microsoft Access (this is a joke).

They generally mean to use a separate database application, that runs on a server. This will have access controls, multi user access and depending on the database, an enforced schema.

SQL is a query language that is generally used for relational databases. There are also a lot of databases that don’t use sql, for various reasons. A relational database and SQL is a good place to start learning about databases though. Postgres is a really common one these days.

As far as using a database, you’d need to set up a database - you can find guides as to how to do this locally. You can then run queries against it using the command line or an application like pgAdmin. You could also make a program that utilizes it.