QLDB Limitations that you should be aware of

Let’s examine QLDB’s restrictions in this post, which are primarily horizontal restrictions. If you haven’t read my earlier piece regarding QLDB’s introduction, click here.

QLDB limitations are classified as follows

• Default quotas
• Fixed quotas
• Document size
• Transaction size
• Naming constraints

Default quotas

The default quotes include restrictions on the maximum number of active ledgers, active journal exports, and active journal data streams.

The default quotas are listed in tabular form below.

Fixed quotas

QLDB has the following fixed quotas per ledger in addition to default quotas. These quotas cannot be increased through the use of Service Quotas:

An active session is the equivalent concept in QLDB. A session is conceptually similar to a user login in that it manages data transaction requests to a ledger. An active session is one that is currently carrying out a transaction. It could also be a session that just finished a transaction and the service anticipates starting another one right away. QLDB allows for one active transaction per session.

Document size

A document encoded in the IonBinary format can be up to 128 KB in size. We are unable to provide an exact limit for the size of an IonText document because the conversion from text to binary varies greatly depending on the structure of each document. Because QLDB supports documents with open content, the size calculation varies depending on the structure of the document.

Transaction size

A transaction in QLDB can be up to 4 MB in size. The size of a transaction is determined by adding the following factors together.

Deltas

The document changes caused by all of the statements in the transaction. The total delta size in a transaction that affects multiple documents is the sum of each affected document’s individual delta.

Metadata

The transaction metadata generated by QLDB and associated with each affected document.

Indexes

If an index is defined on a table that is affected by the transaction, the index entry associated with it generates a delta as well.

History

Because all document revisions are persisted in QLDB, all transactions also append to the history.

Inserts : Every document that is added to a table has a copy added to its history table. A newly inserted 100 KB document, for example, generates at least 200 KB of deltas in a transaction. (This is an estimate that excludes metadata and indexes.)

Updates : Any document update, even if it is for a single field, creates a new revision of the entire document in history, plus or minus the update delta. This means that even a minor change in a large document will result in a large transaction delta. Adding 2 KB of data to an existing 100 KB document, for example, generates a new 102 KB revision in history. The total deltas in a transaction must be at least 104 KB. (Once again, this estimate excludes metadata and indexes.)

Deletes : Delete transactions, like updates, create a new document revision in the history. The newly created DELETE revision, on the other hand, is smaller than the original document because it contains no user data and only metadata.

Naming constraints

The following table describes naming constraints within Amazon QLDB.

Some of the reserved keywords are mentioned here.

In the following articles, we’ll learn more about QLDB’s use cases and where it fits best.

About the author

About CodeStax.Ai

At CodeStax.Ai, we stand at the nexus of innovation and enterprise solutions, offering technology partnerships that empower businesses to drive efficiency, innovation, and growth, harnessing the transformative power of no-code platforms and advanced AI integrations.

But the real magic? It’s our tech tribe behind the scenes. If you’ve got a knack for innovation and a passion for redefining the norm, we’ve got the perfect tech playground for you. CodeStax.Ai offers more than a job — it’s a journey into the very heart of what’s next. Join us, and be part of the revolution that’s redefining the enterprise tech landscape.