Oracle Advanced Queues (AQ): Concepts, Benefits, and Architecture

The acronym AQ in Oracle stands for Advanced Queuing. Oracle Advanced Queues provide a database-integrated messaging system that allows applications to exchange information asynchronously using database tables as the transport layer. Because AQ is built into the Oracle Database engine, it inherits core database capabilities such as transactional consistency, security, backup and recovery, and high availability.

In this lesson, you will learn what Advanced Queues are, how Oracle stores messages in queue tables, and why AQ remains a relevant option in Oracle 23c and cloud-enabled deployments. Later lessons in this module will show how to enqueue and dequeue messages, build PL/SQL applications, and configure queue propagation. This page focuses on the concepts and architecture.

Learning objectives

• Understand the role of Advanced Queues as a messaging platform inside the Oracle Database.
• Distinguish between messages, queues, and queue tables.
• Identify common use cases where AQ improves performance and reliability.
• Recognize how AQ fits into Oracle 23c and cloud-enabled architectures.
• See how this overview page relates to more detailed AQ lessons in the module.

Why use messaging inside the database?

Many applications need to perform work asynchronously. For example, an order-entry system may take a customer’s order immediately, then process payment, inventory checks, and shipment in the background. Rather than forcing all systems to be online and synchronized at once, a messaging system decouples producers and consumers of work.

Oracle Advanced Queues implement this messaging layer inside the database. Instead of running a separate message broker, AQ uses Oracle tables to store messages and Oracle background processes to manage delivery. This has several benefits:

• Transactional consistency – messages can be enqueued and database changes committed in a single transaction.
• Unified security model – database users, roles, and privileges control who can enqueue, dequeue, or manage queues.
• Operational simplicity – fewer moving parts to install, patch, and monitor.
• Integration with existing tools – AQ can be monitored and managed using data dictionary views, PL/SQL packages, and Oracle Enterprise tooling.

Core AQ building blocks: messages, queues, and queue tables

At the logical level, Advanced Queuing revolves around three core concepts:

• Message – a single unit of data describing an event or work item, such as a “New Order” notification or “Invoice Generated” event.
• Queue – a named logical container that holds messages awaiting processing. Producers enqueue messages into a queue; consumers dequeue them.
• Queue table – a physical Oracle table used to store the messages for one or more queues. Queue tables are created and managed through AQ administration packages, not by ordinary DDL alone.

The following figure shows how these concepts relate in a cloud-enabled Oracle 23c database:

Queue tables: how messages are stored

A queue table is a specially created Oracle table that holds messages for one or more queues. You do not manually design its columns; instead, you specify message characteristics and storage options, and Oracle builds the underlying structure for you. The queue table:

• Stores message metadata (ID, enqueue time, expiration, priority, state).
• Stores message payloads (object types, RAW, XML, JSON, or user-defined types depending on configuration).
• Supports transactional operations so that enqueue/dequeue can be committed or rolled back with other SQL changes.
• Uses indexes and internal structures optimized for message lookup and ordering.

In Oracle 23c, queue tables can participate in modern features such as improved JSON handling and enhanced partitioning strategies (where appropriate for performance and lifecycle management). The key idea for this lesson is that queues are logical, while the queue table is the physical storage.

Queues and consumers

A queue is defined on top of a queue table. Each queue has its own:

• Name and schema ownership.
• Configuration options (e.g., single-consumer vs. multi-consumer).
• Association with one or more subscribers or consumers.
• Policies (retention, ordering rules, and visibility options).

Consumers can be PL/SQL blocks, background jobs, middle-tier services, or external applications using database connectivity. In Oracle 23c and cloud-enabled environments, AQ consumers might be:

• Microservices connecting through Oracle Net and processing messages as part of an event-driven workflow.
• Batch jobs that periodically dequeue work for offline processing.
• Integration components that transform AQ messages into other messaging systems or APIs.

Advanced Queues in Oracle 23c and cloud-enabled deployments

While the core AQ concepts are consistent with earlier releases, Oracle 23c and cloud-enabled deployments place AQ in a broader ecosystem:

• Cloud databases – AQ can run inside Oracle Cloud Infrastructure (OCI) databases, allowing messaging to remain close to operational data.
• Modern data types – support for JSON and richer object payloads enables more flexible message formats.
• Integration patterns – AQ can connect to microservices, REST endpoints, and other systems that treat the database as an event source.
• Performance tuning – queue tables can be partitioned or placed in specific tablespaces to align with your performance and storage strategies.

In all these scenarios, AQ remains a database-native alternative to external message brokers, especially when you want to keep business data and messaging guarantees inside the same transactional boundary.

When to use Advanced Queues

Advanced Queues are particularly useful when you need:

• Asynchronous processing – work can be queued and processed later, decoupling user interactions from back-end tasks.
• Guaranteed delivery – messages should not be lost when a database transaction is committed.
• Order control – messages for a particular key or business entity must be processed in a defined order.
• Tight coupling to database state – the success of a business transaction and the creation of a message should be atomic.

If your architecture already depends heavily on the Oracle Database, AQ can be simpler and more maintainable than running a separate message broker—especially for small to medium integration workloads that benefit from transactional guarantees and centralized administration.

Performance and reliability considerations

Because AQ runs inside the database, performance and reliability are closely tied to standard Oracle tuning practices:

• Redo and undo – messages are protected by redo logging and undo, just like regular table data.
• Indexing and storage – message lookup performance depends on well-designed queue table storage and indexing options.
• Concurrency – multiple producers and consumers can operate concurrently, and dequeue options can control visibility and locking behavior.
• Backup and recovery – messages are included in database backups and are subject to standard recovery procedures.

Later lessons in this module will show how enqueue and dequeue options affect concurrency, how to configure retention and message expiration, and how to tune queue tables for performance.

How this page fits into the Advanced Queues module

This page is the conceptual foundation for the Advanced Queues lessons. Use it as your reference for what AQ is and how its core components fit together. The following pages build on this material:

• How to Enqueue and Dequeue Messages in Oracle AQ (PL/SQL Tutorial)
  Focus: practical enqueue/dequeue examples and processing patterns in PL/SQL.
• PL/SQL Tutorial: Building a Complete Oracle AQ Application
  Focus: end-to-end example that creates queue tables, queues, and application logic.
• Oracle Queue Propagation: Distributed Messaging and Propagation Paths
  Focus: moving messages between queues and databases, including cloud-enabled scenarios.
• Conclusion: Key Takeaways from Oracle Advanced Queues (AQ)
  Focus: summary, best practices, and when to choose AQ in real-world designs.

Once you are comfortable with the ideas presented here—message, queue, queue table, and the overall AQ architecture—you will be ready to explore the implementation details in the remaining lessons of this module.