sigmod-writing-style

SIGMOD Writing Style

SIGMOD prose is engineering argumentation: a reader who builds database

systems should finish page one knowing what breaks today, what mechanism you

built, and what measurement proves it. The 12-page ACM-template budget

(references excluded) is generous by conference standards, which removes the

usual excuse — at this venue, missing detail reads as concealment rather

than compression.

Page-one contract

Within the first page, in some order: the workload or application pressure

that makes the problem real now; why the incumbent technique fails at that

pressure point (with a number if possible); the mechanism in one concrete

sentence; the headline measured result with its setting attached; and the

contribution list phrased as artifacts a reader can verify — an algorithm, a

system component, a proof, an evaluation.

A first paragraph that opens with "Data volumes are growing exponentially"

has already spent its welcome; open instead inside the specific bottleneck.

The running example

The single most recognizable SIGMOD stylistic device: one small, concrete

example — a table, a query, a workload snippet — introduced in Section 1 or 2

and threaded through the design sections. Every operator, data structure, or

protocol step is shown acting on it. Papers that explain a join algorithm

purely in symbols, when three rows and two tables would show it, get "hard to

follow" reviews from people fully capable of reading the symbols.

Claim scoping for systems numbers

| Draft claim | Survives review as |

|---|---|

| "Up to 10x faster than X" | "10x on skewed reads at sf=100; 1.3x on uniform writes (Fig 8)" |

| "Scales linearly" | "Near-linear to 64 cores; contention flattens beyond (Fig 9)" |

| "Negligible overhead" | "3-6% p99 latency overhead across the mixes tested (Tab 4)" |

| "Guarantees consistency" | "Snapshot isolation; serializable with Sec 4.3's lock, at cost Y" |

| "First system to..." | Scoped precisely, or cut — a PC full of builders will find prior art |

The pattern: attach every superlative to a figure, a workload, and a

boundary. Database reviewers respect a stated limitation and hunt an

unstated one.

Architecture before algebra

• One system-overview figure early, with components named identically in

figure, prose, and evaluation — nomenclature drift across 12 pages is a

real and common defect.

• Pseudocode for the core mechanism only; secondary routines are prose plus

a pointer to the artifact.

• Correctness arguments get a proof sketch in the body and full detail in

the extended report (sigmod-supplementary), but the invariant itself

must be stated in the body, precisely.

• Design-decision paragraphs ("we chose B over A because...") are not

filler here; they are what industrial readers cite the paper for.

Anonymity-safe voice

Write about your own prior systems in the third person, and scrub the tells:

"we extend the engine of [12]" not "we extend our engine [12]"; no

internal codenames that a search engine maps to a company; no "deployed at a

major cloud provider" phrasing that narrows the author set to two teams.

These rules bind for the entire multi-round review, including revised text.

Budgeting the 12 pages

p1      Problem, failure of incumbents, mechanism, headline number
p2-3    Background + running example; the example does the teaching
p4-7    Design: architecture figure, core algorithm, invariants
p8      Correctness/complexity sketch; report carries the full proof
p9-11   Evaluation: setup table first, then claims in figure order
p12     Related work in contrast form + limitations + conclusion

Treat the evaluation-setup half page as immovable: hardware, datasets,

workloads, baselines, tuning provenance. Cutting it to rescue a design

subsection trades a clarity comment for an evidence objection — a bad trade

in this reviewer pool.

Title and abstract mechanics

• System papers at this venue conventionally lead with the system name and

a colon-scoped promise ("X: <mechanism> for <setting>"); earn the name by

making the mechanism clause precise, not grand.

• The abstract must contain at least one number with its setting attached;

an abstract with zero measurements signals a position paper.

• Avoid "novel," "framework," and "holistic" — three words this reviewer

pool has learned to read as absence of specifics.

• The abstract's last sentence should say what is released: code, data,

scripts. PACMMOD's sharing expectation makes silence conspicuous.

Sentence-level habits

• Present tense for the system's behavior, past tense for what experiments

did.

• Numbers over intensifiers: "2.1x" not "significantly"; "p99" not "tail".
• Name the enemy precisely: "log-structured merge amplification" beats

"performance issues of existing approaches".

Output format

[Page-one audit] pressure / incumbent failure / mechanism / number present?
[Running example] exists and threads through design sections yes/no
[Claim ledger] each superlative -> figure + workload + boundary
[Voice sweep] third-person self-references, codename leaks
[Budget check] section allocation vs. the 12-page plan
[Priority rewrites] ordered list