-
Notifications
You must be signed in to change notification settings - Fork 504
Iceberg wasm blog post #6260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Iceberg wasm blog post #6260
Conversation
Deploying duckdb-web with
|
| Latest commit: |
2305105
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://0cf702de.duckdb-web.pages.dev |
| Branch Preview URL: | https://iceberg-wasm.duckdb-web.pages.dev |
carlopi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reorganized some logic a bit, main changes are:
- using client-server and client-is-the-server consistently in italics
- refactoring third section (iceberg with duckdb-wasm) to be "Iceberg with DucKDB in the Browser", first goal, then shema, then how we got there
- always referred to DuckDB-Iceberg as DuckDB-Iceberg extension
Unsure if all make sense obv.
Tmonster
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! A couple of comments.
I worry there is not enough visual difference between the "client-is-the-server" image and the Iceberg with DuckdDB-Wasm image. I feel the 'client-is-the-server" image does not convey the point that a service needs to be installed and managed locally
| Iceberg is an Open Table Format, that is to say a database stored as a collection of Parquet files (on object storage), metadata on those files (also static files on object storage) and a REST API to orchestrate data and metadata. | ||
|
|
||
| There are two common ways to interact with Iceberg catalogs: | ||
| * The *client–server model,* where the compute part of the operation is delegated to a managed infrastructure – such as the cloud. Users can interact with the server by installing a native client or a lightweight client such as a browser. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we mention any other server options (e.g spark, pyiceberg) to give an example to users? Or do we think the mention of DuckDB below is enough?
|
|
||
| ## Conclusion | ||
|
|
||
| DuckDB-Iceberg is now supported in DuckDB-Wasm for Iceberg REST Catalogs. At the moment only one major implementation works out of the box, more hopefully to follow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure only one? Maybe we should clarify that S3Tables is the only known catalog to work out of the box, with a other tested catalogs failing to support this due to CORS policy limitations.
I guess my question is -- Is there any danger if this statement is incorrect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"DuckDB-Iceberg extension is now supported in DuckDB-Wasm for Iceberg REST Catalogs. As of the time of publishing, this is tested and known to be working end-to-end in a major Iceberg vendor."
omitting making statement about other vendors? (either positive or negative)
Co-authored-by: Tom Ebergen <[email protected]>
Those are likely more questionable / need to be reviewed more carefully.
No description provided.