Information on Service 'ADQL Query'

[Use this service from your browser]

Further access options are discussed below

An endpoint for submitting ADQL queries to the data center and retrieving the result in various forms.

For a list of all services and tables belonging to this service's resource, see Information on resource '__system__/adql'

Service Documentation

About this service

To find out what tables are available for querying, see the ADQL table list.

Be sure to read Standards Compliance below.

About ADQL

ADQL is the Astronomical Data Query Language, an extension of a subset of the Standard Query Language SQL. Its purpose is to give you a formal language to specify what data you are interested in.

To get started using ADQL, try our ADQL course first. There are plenty of introductions SQL itself, which are perfectly useful for learning ADQL. Check your local bookstore. Online, A Gentle Introduction to SQL or chapter three of Practical PostgreSQL might be useful; for the purposes of learning ADQL, you can skip everything talking about "DDL" in general introductions.

Finally, if you're serious about using ADQL, you should at least briefly skim over the ADQL specification.

Also have a look at the TAP examples

Local guide

Standards Compliance

If you give no TOP clause, the system will automatically restrict your matches to 2000 rows. This is mostly for your own protection. If you want more rows (make sure you don't throw them at your browser, i.e., select VOTable output), use SELECT TOP 100000 or something along those lines.

In particular, when doing set operations (e.g., UNION) in STC-S, no conforming of coordinate systems will be performed.

The output of ADQL geometries follows the TAP standard (simplified STC-S) rather than the ADQL standard (something similarly messy).

ADQL defines coord_sys (the first argument to the geometry functions) to be a string_value_expression; thus, you can have column references or concatenations or basically anthing there. We only allow string literals containing one of the defined coordinate systems there (these include at least the empty string, GALACTIC, UNKNOWN, ICRS, FK4, FK5, and RELOCATABLE), or NULL.

SELECT and SELECT ALL are not exactly the same thing. The latter will add an OFFSET 0 to the resulting postgresql query. Use this when the query planner messes up; see the guide star example.

Date literals can be specified as for Postgresql; you always need to use strings. So, '2000-12-31' or 'J2416642.5' are both valid date specifications. See also the historic plates example.

The ADQL does not allow boolean columns. Within the data center, we do have boolean columns here and there, and it would be shame to dumb them down to integers. They show up as INTEGERs in TAP_SCHEMA, though. When you try to compare integers to them, you get an error message to the effect that an "operator does not exist: boolean = integer". To query against such columns (and have valid ADQL), use col='True' or col='False'.


Hint: You can send off your query by typing control-return from within the input text box.

Error messages for parse (and other) errors are not always as helpful as we would like them to be. Feel free to complain to us with concrete examples of where we messed up, and we'll try to improve.


You can access this service using:

This service is published as follows:

local means it is listed on our front page, ivo_managed means it has a record in the VO registry.

Input Fields

The following fields are available to provide input to the service (with some renderers, some of these fields may be unavailable):

NameTable Head DescriptionUnitUCD
_TIMEOUT Timeout after Seconds until the query is aborted. If you find yourself having to raise this beyond 200 or so, please contact the site operators for hints on how to optimize your query s N/A
query ADQL query A query in the Astronomical Data Query Language N/A N/A

VOResource XML (that's something exclusively for VO nerds)