In an SAP system you run yourself, a growing database is an infrastructure problem. Somebody buys disk, the backup takes longer, life goes on. Under RISE it is a line on an invoice — and a line you renegotiate from the worst possible position: mid-contract, with the system already in production and no alternative supplier.

It is the difference almost nobody weighs at signature. The contract fixes a volume, the volume is sized with today’s data, and the growth of the next three to five years is priced at mid-term rates.

Why growth costs differently under RISE

Three characteristics of the model combine, and their effect is multiplicative rather than additive.

The volume is contractual, not technical. You do not buy disk — you buy an entitlement to volume. Going past it does not make anything slow, it makes something billable, negotiated when you are already inside.

Sizing moves in steps. HANA memory is not sold by the loose gigabyte: there is a contracted base and extensions sold in blocks. Growing a few gigabytes past the step forces you to buy the whole next step. The cost is not proportional to the growth — it is a staircase.

The term is long. Three to five year contracts mean a wrong sizing decision is not corrected next year: it is paid until the end of the term.

Put the three together and the asymmetry that matters appears: the moment to act is before you touch the step. Once you have climbed it, reducing volume rarely gives money back — the commitment is signed. The value of taking weight out of the database is not in undoing the step you paid for; it is in not paying the next one.

SOFFCONT1 is the most obvious candidate there is

Every SAP database with a few years on it has this table, grown without anyone deciding. It is where GOS attachments are kept inside the database: the PDF somebody dragged onto an order, the email that became a document, the spreadsheet attached to a purchase order.

It is the right target for three reasons that rarely coincide:

It is not business data. Taking accounting line items out of there requires an archiving project, a retention rule and a conversation with tax and audit. Attachments do not — they keep existing and keep being accessible, just somewhere else.

Nobody decided to put them there. It is the default behaviour when no content repository was ever configured. There is no business rule to preserve, only a setting that was never made.

It never stops growing. It is the one part of the database that grows with people’s habits rather than with transaction volume. And habits do not shrink on their own.

How Cloud Storage becomes an SAP content repository

Here is the part that changes the arithmetic, and it is less known than it should be.

SAP stores external content through ArchiveLink, and ArchiveLink talks to an HTTP content server. Historically that meant one more machine: install SAP Content Server, license it, monitor it, patch it, add it to the recovery plan. A good share of the gain from taking attachments out of the database went into that server.

The ABAP SDK for Google Cloud solves this elegantly: it ships an HTTP handler written in ABAP, published on an SICF node inside the system itself. ArchiveLink sees it as an ordinary content server; the handler takes the call and writes — or reads — the object straight into the Cloud Storage bucket.

The system talks to itself, and the only new component in the landscape is a bucket. There is no content server to install, license or maintain.

The design comes down to four pieces:

• a service account on Google Cloud with write permission on the bucket;
• the SICF node that publishes the SDK handler;
• a content repository created in OAC0, of type HTTP content server, pointing at that node;
• the link between document types and the repository, in OAC3, so new attachments are born outside the database.

For what is already inside SOFFCONT1, the relocation is done by SAP’s own report — and that is where the trap lives, which we cover in detail in SOFFCONT1 and RSIRPIRL: the step that looks like a failure. Worth reading before running it, not after.

Two reality notes about the SDK: the edition that applies here is the on-premises or any cloud one, which is the supported edition on S/4HANA Cloud Private Edition — that is, RISE. And the size limit per object is Cloud Storage’s own, 5 TB, which for a GOS attachment is endless headroom.

The arithmetic — and the two numbers only you have

The calculation cannot be published ready-made, because half of it lives in your contract. But the structure is simple and fits in a one-tab spreadsheet.

On the SAP side, three measurements: how many GB SOFFCONT1 occupies today; how much it grew in the last twelve months; and how many GB you are from the next sizing step. That third one decides the urgency — and it is the one almost nobody has at hand.

On the contract side, one number: what an additional GB costs under your agreement, at today’s price and not at signature price.

On the Google Cloud side, one choice: the storage class. An attachment the user opens from the order screen needs a standard class with immediate reads. An attachment from a closed fiscal year, which only comes back during an audit, fits a cold class — far cheaper per GB, with a retrieval cost when it is read. Mixing the two is the expensive mistake: putting live attachments in a cold class turns every user click into a wait and a fee.

The orders of magnitude are usually so uneven that the spreadsheet answers itself. What it does not answer — which is why the next section exists — is whether the result shows up on the invoice or only at the next renewal.

What goes wrong, by name

Believing that shrinking the database shrinks this month’s invoice. It does not. The volume commitment is signed. The gain appears when the next step is not needed — which is enormous, and is different from immediate savings. Promising the second thing to get the project approved is how the project loses credibility at the first report.

Treating it as a technical project inside a system that is not yours. Under RISE, SAP operates. Installing the SDK transport, creating an SICF node and opening the network path to the bucket all go through the contract’s operating process. Doing it as a surprise is not agility — it is starting a support-boundary argument at the worst moment.

Confusing taking it out of the database with deleting it. The table holds the real content of the attachment. All the value is in relocating; none of it is in deleting.

Trading a space problem for an availability problem. With content outside the database, opening an attachment now depends on the network and on the bucket answering. It is a good trade, but it is a trade — and what the database team used to monitor now needs monitoring of its own.

Migrating everything at once. High volume in a tight window, with no prior count by range, is how a migration becomes an incident instead of a project.

The honest limit

Taking attachments out of the database reduces growth. It does not solve what sits behind it: nobody ever decided what should be attached to SAP in the first place. The table starts growing again, more slowly, for the same reason as before. Without a rule about what gets attached and for how long, this is postponing, not fixing.

It is also not the only source of weight. Attachments are usually the largest share you can remove without a business project, but if the goal is genuinely to shrink the environment, they are the beginning — the rest needs archiving with a retention rule, which is different work and a different conversation.

And there is a cost that moves rather than disappears: it leaves SAP’s invoice and lands on Google Cloud’s. Far smaller, with the order of magnitude in your favour — but it now exists, and it needs an owner and follow-up.

If the starting point is knowing how much of your database is attachments and what can come out, begin with SAP archiving — SOFFCONT1 is usually only one of the large tables. If the conversation is about the whole contract and not just space, see FinOps for SAP RISE. And if the larger goal is understanding the environment before touching it, the path is the IT diagnostic.

Frequently asked questions