Artis is a rapidly growing fintech company building innovative financial products focused on fast-moving market data. We provide powerful grid-based data displays (AG Grid) and real-time candlestick charting (TradingView Lightweight Charts) to our expanding user base.

We’re looking for a Lead Front-end Developer who: - Is an expert in React and TypeScript. - Has strong knowledge of Web Workers and performance optimization. - Can effectively lead and mentor a growing front-end team.

Bonus points for experience with: - WebAssembly (WASM) - Rust - Real-time/multiplayer applications - Working with financial data and financial products

You’ll thrive if you: - Enjoy solving challenging performance and scalability problems. - Prefer minimal bureaucracy and straightforward collaboration tools (Linear, Slack). - Are comfortable working remotely within UK working hours. (London-based is a plus, not mandatory.)

Salary: £100,000 – £120,000 per year. Apply directly at: careers@artis.works

Artis Works leads financial innovation by empowering trading firms, brokerages, and institutions with advanced technology. Our flagship product is responsible for taking high frequency tick data from the market, and combining it with user supplied data and custom formulas to produce insights for traders. We surface high quality, low latency historical and live data across 4 continents.

See more about the product at https://artis.works

Position Overview:

We're looking for a motivated backend engineer to join our dynamic team. You'll design, build, and launch essential cloud services from the ground up, significantly impacting our products and success.

Requirements:

Experienced or interested in Rust, or proficient in JVM-based languages (especially Clojure).

Skilled in building real-time data processing and multi-threaded, latency-sensitive systems.

Familiar with stream processing (Kafka, Pulsar, Flink) and distributed systems.

Capable of building secure, scalable, and reliable systems with attention to monitoring and graceful failure.

Experienced with relational, non-relational, and time-series databases.

Familiarity with cloud infrastructure, especially AWS, is a strong advantage.

To apply send an email with a cover letter and/or CV/Resume to careers@artis.works

https://lowtechguys.com/rcmd/ - no affiliation, and probably other similar options are available

And is there a story for replication/subscribing to queries for real time updates?

Postgres is so powerful partly because of its ecosystem, so I want to know how much of that ecosystem is still useable if I’m using gel on top of Postgres

> If I use some other extension like timescale is that compatible with gel [...] Postgres is so powerful partly because of its ecosystem, so I want to know how much of that ecosystem is still useable if I’m using gel on top of Postgres

Playing nice with the ecosystem is the goal. We started off with more of a walled garden, but with 6.0 a lot of those walls came down with direct SQL support and support for standalone extensions [1]. There is a blog post coming about this specifically tomorrow (I think).

> And is there a story for replication

Replication/failover works out of the box.

> subscribing to queries for real time updates?

Working on it.

> so can I add gel to an existing Postgres instance and get the benefits of the nicer query language or does it rely on special tables?

Gel is built around its schema, so you will need to import your SQL schema. After that you can query things with EdgeQL (or SQL/ORM as before).

[1] https://github.com/geldata/gel-postgis

We'll continue bridging the gap to make it easier for companies to adopt Gel for an existing database. We either will invest in creating a tool for migration, or maybe some more exciting options we're currently pondering on.

The XTDB team has pivoted towards a SQL-first approach (though still supports datalog) and now 'only' has the 'But why not just use Postgres' problem to solve.

Having personally moved from trying to use Postgres for everything (including lots of timeseries data with Timescale) to a dedicated and relatively unknown DB built purely for the purpose I want it for (QuestDB), I am all for more people trying to build databases that do specific things better than Postgres. However, it will be very difficult to create something that does literally everything Postgres can do but better, which probably makes Postgres the sensible choice for the majority of applications.

Not sure on your definition of 'people', but I think every business ultimately wants solid auditing and reporting capabilities across their IT systems.

These concerns are only increasing in importance as new regulations demand stronger data provenance, but their implementation shouldn't be reliant on the process of "proper schema design" to get things right first time.

Databases built for the modern world should be making this stuff bulletproof and easy.

(I work on XTDB - and if Postgres already supported temporal tables I possibly wouldn't!)

I'm fully on board with XTDB and similar solutions for this reason. Most people still gravitate towards Postgres and similar databases without giving much thought to these temporal challenges, even though those options lack a robust solution for the temporal issues that so many systems demand.

We’re building a collaborative, local-first set of tools that take raw financial market data from multiple financial exchanges and allows users to create excel-like formulas using both the market data and user-entered data as inputs. The problems we are solving are extremely challenging, but we have delivered a working V1 and have a rapidly growing dedicated user base and recently secured VC funding.

Both roles are for senior developers:

  - Frontend is React/strict TypeScript/local-first DB + sync engine, custom formula evaluation engine written in rust compiled to WASM (no Rust/WASM expertise necessary for this role)
  - Backend is mostly Rust + some Clojure (no Clojure experience needed), k8s/Postgres Aurora, QuestDB, Kafka.

We try to keep red tape and bureaucracy to a minimum and mostly just use linear and slack for collaboration but are always open to process suggestions from anyone on the team.

Apply at https://www.artis.works/careers or DM me/reach out to alex at artis.works.

Overall triplit has been really great, both as a frontend dx and also their support - whenever we find an issue or have a feature it gets handled very quickly by the team which is awesome!

As soon as they have an answer for HA deployments we will be moving more critical data there instead of Postgres

I don't think this is true, granted there are some big challenges to transfering data between devices without a central server, but there are several projects like https://dxos.org/ which use p2p, and also there's https://ditto.live/ which uses bluetooth/wifi direct for cases where all users will be in the same room or on the same local network (imagine wanting to play chess with a friend sitting in a different row on a plane without wifi - I was in this situation recently and was pretty surprised that I couldn't find anything on the app store that could do this!)

Of course most of the time its better to have a server because p2p still has a lot of difficulties and often having a central 'source of truth' is worth the costs that come with a server based architecture. So imo things like https://electric-sql.com/ or https://www.triplit.dev/ or the upcoming https://zerosync.dev/ will be far better choices for anyone wanting to build a local first app used by many users.