Apache Amoro puts a management layer over Iceberg, Hive and Paimon tables

A management layer for tables that outlive the job that wrote them

Apache Amoro sits in the layer that most lakehouse teams end up building for themselves: the one that keeps tables healthy after the writing job has finished. The project describes itself as a Lakehouse management system built on open data lake formats, and the emphasis falls on management rather than on inventing a new storage format. That framing decides who should look at it. If your problem is getting data into the platform, Amoro is the wrong tool. If your problem is that a Flink job emits a stream of small files, or that a Hive table and an Iceberg table live in two separate catalogs, or that nobody has deleted a snapshot from last year, then a management layer is exactly what is missing. Amoro is written in Java, is released under Apache-2.0, and is still an incubating project inside the Apache Software Foundation.

AMS owns the catalog, plugins do the work

The components are easy to separate once you read the architecture notes. The Amoro Management Service, abbreviated AMS, provides the management features such as self-optimizing and data expiration, and it also provides a unified catalog service for all compute engines that can be combined with an existing metadata service such as Hive Metastore or AWS Glue. Around that core sit plugins. The optimizer plugin is the self-optimizing execution engine, the terminal plugin offers SQL command line tools with local Spark and Kyuubi implementations, and the LogStore plugin is described as providing millisecond to second level SLAs for real-time data processing based on message queues like Kafka and Pulsar. The repository layout reinforces that split, with separate modules for amoro-ams, amoro-optimizer, amoro-web, amoro-metrics, an amoro-openapi-sdk and a format module for each supported format, plus amoro-mcp-server, amoro-format-hudi and amoro-format-lance.

Four table formats, and one of them is only inspected

Amoro supports four table formats, and the differences between them decide where the system can be placed. With the Iceberg format, users hand their Iceberg tables to Amoro for maintenance while keeping the full set of Iceberg table features. Mixed-Iceberg adds a set of more optimized formats for streaming update scenarios on top of Iceberg, aimed at workloads with high performance requirements on streaming updates or a need for CDC incremental data reading. Mixed-Hive is the migration path: a Hive table is upgraded to Mixed-Hive through metadata migration only, and the original Hive tables can still be used normally, which is the argument for teams that do not want to disturb business built on Hive. Paimon is the odd one out. Amoro supports displaying metadata information in the Paimon format, including Schema, Options, Files, Snapshots, DDLs and Compaction information, which reads as inspection rather than management.

The mixed format support matrix has holes worth reading first

The most useful thing the project publishes is a per engine support table for the mixed format, because it shows where the combinations end. Flink 1.18.x, 1.19.x and 1.20.x cover batch read, batch write, streaming read, streaming write and create table, but batch overwrite and alter table are marked unsupported. Spark 3.3, 3.4 and 3.5 cover batch read, batch write, batch overwrite, create table and alter table, with no streaming read or streaming write. Hive 2.x and 3.x, and Trino 406, are the narrowest rows: batch read, batch overwrite and alter table, with no batch write, no streaming read or write, and no create table. A team that plans to stream through Flink and then run analytical overwrites in Spark can cover both, but a team that expects one engine to do everything cannot.

Self-optimizing runs asynchronously, which is the point

The optimizer plugin is the part that decides whether Amoro earns its place. It is described as an asynchronous execution engine that performs merging, sorting, deduplication, layout optimization and other operations on all type table format tables. Asynchronous is the operative word here, because maintenance then happens outside the query path instead of competing with the dashboards reading the same table. The README lists compacting small files, handling change files and regularly deleting expired files as part of the same loop, and names both query performance and storage cost reduction as the outcome. The LogStore plugin is the near real time counterpart on the write side. What the documentation does not give you is a sizing guide, so how many optimizer workers to run against a given table volume is something you have to determine against your own data.

The deployment pieces are in the repository, the install steps are not

This is the thinnest part of the documentation, and it is worth being blunt about it. The project tells readers to learn more at amoro.apache.org and to reach the community through the mailing list, but the README does not contain a step by step installation. The repository does show the shape of a deployment: a docker directory, a charts directory for Helm style packaging, a dist directory, and a Maven wrapper mvnw with a pom.xml at the root, alongside build, dev, docs, grafana, http and tools directories. The reader is therefore left to work out the container image, the service configuration and the catalog backend on their own. Once the service is running, the terminal plugin with its local Spark and Kyuubi implementations and the WEB UI are the two documented ways in.

An incubating project with a licence that covers binaries

The repository is not archived and the last push was on 2026-10-15, so the code is still moving. The release history is short and clearly marked incubating: v0.8.1-incubating on 2025-09-11, v0.8.0-incubating on 2025-05-08 and v0.7.1-incubating on 2024-11-20. Those gaps are months rather than weeks, so treat an upgrade as a planned event. Once Amoro manages a table, format level changes can reach the physical layout of data that existing queries already read, and there is no documented rollback in the README. On licensing, the project uses Apache-2.0 and carries LICENSE, LICENSE-binary, NOTICE and NOTICE-binary files at the root plus a licenses-binary directory, so redistributed binaries carry the standard attribution and notice obligations. Review the licenses directory for the artifacts you mirror internally rather than assuming one file covers the whole distribution.

Editorial conclusion

Amoro fits teams that already run Flink, Spark, Hive or Trino against open table formats and cannot spare the engineering time to write compaction, expiration and catalog glue themselves. It is a poor fit if you need a single engine to do everything, since the mixed format support matrix has real gaps, and a poor fit for teams that only want managed Iceberg without a service to operate. Before adopting, check the engine and operation pairs your workload needs against the mixed format support table, then read the deployment and configuration pages on amoro.apache.org, because the README does not document a full install sequence or a rollback path.

Frequently asked questions

Official sources

1. apache/amoro on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases