The difference between message queuing technologies (e.g. IronMQ, RabbitMQ, Amazon SQS etc.) and RDBMSs (e.g. Sqlite, Sql Server, PostGres etc.) is that if you use RDBMS tables as queues and want to allow querying then you will have to manage the LIFO queuing process yourself. Queues (with some exceptions) enforce a LIFO process while Database tables are random access and do not enforce how or when data is inserted, modified or removed. Those rules are handled in the business layer. (You mentioned using Python and Sqlite. Sqlite would be your queue/data store and a Python app would perform the logic of managing the LIFO queue as well as random querying.)
RDBMSs are often used as intermediary message stores and from your question I'm guessing that a LIFO queue isn't even that important since you seem to be interested in random access above everything else. It's hard to tell without knowing more about what you're designing. But if you want something that works like a Queue and a Database off-the-shelf then check out Oracle AQ.
From the linked page:
Because Oracle Streams Advanced Queuing is implemented in database
tables, all operational benefits of high availability, scalability,
and reliability are also applicable to queue data. Standard database
features such as recovery, restart, and security are supported by
Oracle Streams Advanced Queuing. You can use database development and
management tools such as Oracle Enterprise Manager to monitor queues.
Like other database tables, queue tables can be imported and exported.
Messages can be queried using standard SQL. This means that you can
use SQL to access the message properties, the message history, and the
payload. With SQL access you can also do auditing and tracking. All
available SQL technology, such as indexes, can be used to optimize
access to messages.
More resources and further reading: