Some advanced database people I know don't consider SQLite or Microsoft Access as a database

Then they're not advanced. They just think they are. Both are databases. They store data.

I would like to know if Microsoft Access is an equivalent database to SQLite or not

Both follow the SQL standard pretty well. MS Access as a 'product' has more bells and whistles - reporting for example, but Access as an engine is the same.

So is SQLite really a database?

SQLite is a library which can talk to a database. Meh - symantics. In answer to your question - yes.

Is SQLite a viable alternative to Microsoft Access?

Depends on your goal. What do you want to do with the database? Use it on an Android? Apple device? Web?

Almost all these questions can easily be answered by you defining the word 'database'. Many of these questions can't be answered unless you define the word 'database'.

Microsoft Access is a program. People who use programs use it. SQLite is a programmer's tool. People who write programs use it. They are not the same sort of thing.

Few people here use Microsoft Access. We don't know much about it. We are not the best people to write about it.

Is SQLite a viable alternative to Microsoft Access?

That depends on your use-case. I can imagine multiple situations for both "yes" and "no" answers. SQLite is more portable and can be embedded almost anywhere. Microsoft Access has a built-in user interface layer and certain other features SQLite's not supposed to have.

Microsoft Access according to you is a database like SQLite?

Why do you care about what other people think? Tell us the problem you want to solve. It's easier for us to help you this way.

What is the difference between SQLite and Microsoft Access on a technical level?

This is a terribly broad question, like ones I used to get for high school essays. Are you interested in the design or the implementation? You can inspect the technical level of SQLite yourself by visiting https://sqlite.org/src or downloading the source code any other way. Microsoft Access can't be as readily inspected, but it could be possible to read their whitepapers and/or perform reverse-engineering to obtain more information.

1. SQLite and MS Access are both relational databases which are file based i.e. are serverless.

2. SQLite and MS Access exist in 32- and 64-bit architectures

3. SQLite is free to deploy but MS Access is proprietary.

4. MS Access is a full feature user interface and database combined.

5. For a user interface, SQLite has a CLI but this is no where nearly comparable with the MS Access user interface.

6. An installed instance of MS Access supports COM (Component Object Model) automation. SQLite does not support COM access.

7. An installed instance of MS Access supports VBA (Visual Basic for Applications) SQLite has no custom programming capability: it exposes a series of APIs (Application Programming Interface).

8. The MS Access database is accessible WITHOUT an installed instance with the Microsoft.Jet.OLEDB.4.0 provider (32 bit only) and the Microsoft.ACE.OLEDB.xx.0 provider (both 32- and 64-bot) where xx = 12, 14, 16 depending on the version of the MS Access engine version. You can create and alter dayabases without MS Access installed.

NOTE: a provider is free software supplied by Microsoft.

SQLite and MS Access are both relational databases which are file based i.e. are serverless.

Incorrect. SQLite is a relational database data manipulation library. It can indeed be used to "create a server" and in fact already has. MS Access is just a hooey-gooey builder. The data manipulation library it accesses IS NOT part of MS Access, though JET does ship with it. That does not mean, however, that out of the box MS Access cannot access a "server", because it can, does, and that is recommended if you require concurrent data access.

SQLite and MS Access exist in 32- and 64-bit architectures

And 2-bit, 4-bit, 8-bit, 16-bit, 128-bit 256-bit, 512-bit and 1024-bit versions.

The "compiler" used to generate the "executable" determines the architecture. Both products compile (and run) just fine using a 4-bit compiler or a 1024-bit compiler. Source code does not determine architecture. The compiler used to compile the source into object form, and the link-loader, determine the specifics of the machine architecture on wich the resulting executable executes.

Having some architecture available merely means that the source code was processed through a compiler and link-loader that produced output executables in that architecture. THat some architecture is not available simply means that no one has yet bothered to compile the source with a compiler and link-loader for that architecture.

Note that it is entirely possible to write software in a non-portable manner such that you need to fart with the source code in order to support a new architecture. This is typical for asshats like Microsoft, no one else has this problem.

MS Access is a full feature user interface and database combined.

Actually, no. MS Access is a hooey-gooey builder that can use a whole collection of "data storage layers" which are entirely independent of MS Access (although some of them, such as JET, are bundled).

An installed instance of MS Access supports COM (Component Object Model) automation. SQLite does not support COM access.

Sure it does, You just have to write it.

An installed instance of MS Access supports VBA (Visual Basic for Applications) SQLite has no custom programming capability: it exposes a series of APIs (Application Programming Interface).

And what, pray tell, do you call SQL? Seems to me that you "send" an SQL program to SQLite and it "returns" the result. Why on earth would I want to "send" VBA to SQLite?

Sure it does, You just have to write it.

An installed instance of MS Access supports COM (Component Object Model) automation out of the box. SQLite does not support COM access.

hooey-gooey

I am not sure what this expression (you have used several times) means precisely but it sounds condescending which adds nothing to the case for using SQLite and does not take anything from the case for using MS Access.

Ms Access is not a database that I will choose to use but SQLite is not an alternative to MS Access because, in my opinion, the two are NOT comparable alternatives.

One wonders what the point of this thread is, then.

Access only runs under Windows - a severe limitation.

Access only runs under Windows - a severe limitation.

That is the foremost reason why SQLite and MS Access aren't comparable alternatives; the other reason is that MS Access has a graphical user interface which has the capability to package it (with forms, views, procedures etc.) as an free standing executable.

I too wondered about the thinking behind this thread but it was raised and deserves a response.

That is the foremost reason why SQLite and MS Access aren't comparable alternatives; the other reason is that MS Access has a graphical user interface which has the capability to package it (with forms, views, procedures etc.) as an free standing executable.

I wouldn't say free. Unless, something has happened in the last few weeks, MS Access has to be bought, or have a paid subscription to be able to use it.

I believe you misunderstood him here. The term free standing executable is an alternate way of writing self-contained executable. He did not say that MS Access was free itself, in terms of pricing, or open source.

I believe you misunderstood him here. The term free standing executable is an alternate way of writing self-contained executable. He did not say that MS Access was free itself, in terms of pricing, or open source.

My apologies. Lack of knowledge of the English language/technical jargon.

Thanks for clarifying and making doubly sure that this is understood without ambiguity.

One further thing that I omitted to mention in my original message and subsequent clarification is that MS Access has the facility to create/contain linked tables from other databases such as MS SQL Server and other ODBC compliant databases including SQLite when its ODBC driver is installed.

A linked table presents the underlying data in a graphical user interface; the underlying data can be used on a read/write basis¹. SQLite does not support linked tables.

¹My experience of this is only with MS SQL Server.

SQLite does not support linked tables.

It does not need to do so. However, you are incorrect. The Virtual Table interface can be used to build a "linked table". An example of a "linked table" ability is the LSM vtab module. There are others.

You can have a virtual table that is "linked" to Active Directory so that you can use meaningful and performant tools to deal with AD (rather than the crap provided by Microsoft).

There is no reason that one cannot write a vtab that implements an ODBC (or other API) to interface with tables in foreign data management systems. I suspect there already are such vtab interfaces written and in use.

SQLite3 is a data manipulation engine that implements a Relational Database organization that one communicates with via industry-standard SQL.

MS Access is a graphical user interface builder. It uses add in database engines to do data manipulation. All tables in MS Access are "linked tables" in that they are tables which are managed by something other than MS Access (such as JET or some external data manipulation engine).

The OP's original question was:

What is the difference between SQLite and Microsoft Access on a technical level?

Your response below does not fit as it addresses a different issue namely What is possible with SQLite?

There is no reason that one cannot write a vtab that implements an ODBC (or other API) to interface with tables in foreign data management systems.

Is denigrating MS Access with such qualifications as crap and hooey-gooey adding anything to this thread (which might be used as a reference in the future)? I do not think so.

"Your response below does not fit "

It does, as it corrects your response.

How does

Sure it does, You just have to write it.

and

There is no reason that one cannot write a vtab that implements an ODBC (or other API) to interface with tables in foreign data management systems.

answer the OPs question:

What is the difference between SQLite and Microsoft Access on a technical level?

The quest is not about what SQLite can be enhanced to do or can do with collateral user-developed software but a comparison of SQLite and MS Access out of the box.

And, where is

as it corrects your response.

the correction that you allude to?

While I would readily accept that you could never turn MS Access into SQLite, I am sure that you could turn SQLite into MS Access with user-developed software. But that is NOT the point of SQLite which is a small foot print and cross platform relational data management library. Put simply, SQLite manages file-based relational databases.

For a user interface, SQLite has a CLI but this is no where nearly comparable with the MS Access user interface.

Many good 3rd party user interfaces are available for SQLite, e.g. my favourites are, SQLiteGUI by Little Brothers on Github for Windows, SQLiteMaster by amos mobile for Android, aSQLiteManager for Android.

Aask said: For a user interface, SQLite has a CLI but this is no where nearly comparable with the MS Access user interface.

These are not meant to be compared; they serve different purposes.

SQLite is only a database program. It lets you define tables, fill them with data, and query the tables. Access is a presentation tool which allows you to access data in any database you want (including Google Sheets and SQLite). Access has it's own native database - the default for normal use. Access lets you define queries and use them in other queries; SQLite does not.

Access lets you define forms for data entry and reports for getting your data in a human readable format. If you want to design an application for users, you need forms and reports. SQLite will give you neither - it stores data.

Microsoft Access is NOT a database system. It is a hooey-gooey for creating a user interface which may communicate with a database system using the Microsoft copied-from-IBM API known colloquially as ODBC. By default, the Microsoft Access User Interface application uses the JET data engine. It may use others (such as SQL Server, Sybase, and on and on -- basically anything for which an ODBC API connector exists).

SQLite3 is a "data manipulation engine" (such as what the hooey-gooey MS Access would communicate with via an ODBC interface) but does not have a hooey-gooey.

In other words, MS Access is a User Interface Builder which "uses" some other storage engine via ODBC.

SQLite3 is a storage engine which may be used by just about any software you can write (including MS Access hooey-gooey builder, which, although not written by you, was written by a third-party to wrap hooey-gooeys around data manipulation engines).

So no. Micrsoft Access is not a "database". Microsoft Access allows creation of clickety-pokey hooey-gooeys which interface with a data management system (such as JET or SQLite3).

In addition to what others have said, I'll add a note that .accdb files for Access are limited to 2GB in size. This is actually what made me look around and find SQLite years ago, when I kept getting annoyed at that tiny limit.

I remember when MS Office started becoming 64 bit, and I thought yay, they'll get rid of that limit. But nope, dang Excel became 64 bit before their Database program. And apparently the limit is still there at 2GB.

As we can see from SQLite you don't need a 64 bit program to access (with a lower case a) larger files. I guess MS just figured well, if they want bigger databases we'll just push them towards SQL Server or something.

SQLite limits page for reference.

And apparently the limit is [still there]

Well, as with everything else Microsoft, they daren't change anything in case it breaks. Also, the guy who wrote it and knows all about it retired years ago, so no one else knows how on Earth it all works. ;)

Thank you for this fine comparison.

SQLite is a little database engine. The application which comes with it supports only text mode.

MS Access is a Rapid Application Development Tool. Only graphics (GUI) mode.

SQLite is a little database engine. Only text mode.

SQLite is a database engine library. It has no mode, text or graphical. The application which uses SQLite as its data manipulation library is what has a text mode or graphical mode interface (or perhaps even a direct-wired-into-the-brain interface).

1. SQLite is database, ms access not is database.
2. SQLite with (SQLiteStudio, SQLite browser, DBeaver, HeidiSQL, AntaresSQL or Popsql) is alternative Ms Access. All solutions are open source and you don't even need MS Access - unless it's mandatory or you want to create reports or something!

Whether Access makes sense in your universe really has everything to do with context and probably a lot less to do with the technical details of the engines.

To get a meaningful answer you'd have to tell us about what app you're trying to build and in what kind of environment it will need to run. Depending on your answers the engine may be incidental. Or you might critically need a feature only SQLite provides. Or you might critically need integrations that are trivial in Access but require a lot of work with some of the solutions above.

You should consider that, in this forum, you're more likely to be getting info from a lot of SQLite fans and generally people who know a lot about SQLite. Contrariwise I am confident I can say that the chief maintainers of the JET engine or the Access UI are unlikely to be present here.

You might also want to ask your question in a forum full of Access users to get a useful info about the JET engine's quirks, or Access's abilities with other backends. Or Access's UI capabilities. Or the value/importance/pains of COM integration with other apps.

Having said that, I think I can say with some authority (having been at MS nearly 30 years) that RED (there's two versions of JET, the one we're discussing here is RED) is not really the favorite engine of the systems groups. Other back-ends are commonly used outside of line-of-business applications. Things may have changed but I doubt it.